Mvc – Why and how are Server-side Web MVC and client-side/desktop MVC not the same

This problem is almost identical to the synchronization one maintain between its code and the database.

Usually, backend code do the same workflow:

1. Request database
2. Create (hydrate) object from raw data
3. Manipulate data
4. If needed, update the database.
5. On the next request (in the case of a web app), you totally invalidate the hydrated objects you have, an begin from point 1. again, as you recognize the database to be the "upstream" source of the data.

From there, I'd say you have 2 paradigms:

Client - server like Server - database

Client to server sync is pretty much the same, you need to setup some cycle, where you consider that your data are still "fresh", then upon the next "action" of your user, query again the server (as you would do with a database), and create your client objects from there.

Push from server to client

Another solution is to have the server "push" the new object states to the client, as soon as it know they have been updated. Such paradigm is use by new frameworks like Meteor: servers listen to the database, wich emit an event upon every update/insert/etc. Servers then update their internals objects, and transmit the event to clients, which do the same (I'm simplifying for the sake of the answer).

Conclusion

In any case, there's no universal solution that you need to add as a library to your project. Caching is hard, like real hard, and you'll need to integrate the server - client constraints to your code, and handle such cache yourself.

I see another method that, unless I've misunderstood your post, hasn't been mentioned:

The main view, post, would have its model. This model would consist of ONLY the properties necessary to display this post (author,title,body, etc). Then, every piece of the post view that you can think of (timeline, tag navigation panel, subscribing panel, etc), would be split into their own views and each one would have its own model. This way, you can build up those models in your controller when you need them.

It might sound like an unnecessary amount of extra work to split these out like this, but it lends itself to the single responsibility principle. Keep each "view/model" focused on itself so that it can be re-used anywhere it is needed.

If you feel that your code is beginning to duplicate itself, which it might depending on your situation, you should consider writing some sort of "helper class." This helper class would handle all of the model build-up in one place, and all other duplicate code would be stripped down to a helper class call.