I am looking to get some input from other users on the benefits of server-side MVC. With the power of many javascript libraries. What good purpose does server-side MVC server anymore?
You can easily use client-side MVC with templating and a REST API to make a much more resposive application with less overhead of reloading a whole page for minor changes.
Server MVC benefits:
- Mature.
- Widely adopted.
- Most of the code is inside server so should be more secure.
But definitely the tendency is to back to client/server computing but instead of fat clients written in C or another language but now you have a very nice platform: The browser.
I have a simple policy about when I use Server side MVC and client side MVC:
- Casual users with few interactions: Server + Ajax.
- LOB application (Accounting, ERP, CRM, etc.): Client.
BTW I use Java Server Faces for #1 and ExtJS backed up by JAX-RS services for #2.
Regards.
The way I see this, the server side MVC remains relevant if you consider the V as your client side MVC wrapped in a black box. The thing is that this is all about collaboration and scalability. The server side MVC continues to fuel the REST APIs (for instance) with the notion that you are technically outsourcing the viewing technology to a separate framework running in your browser.
Since browser is increasingly seen as application development platform, you can export huge amounts of data from your "backend platform" to the client (browser) and then treat the data as a local "database" in your browser allowing fast response time.
Combining these 2 MVC frameworks allows for:
- Sparse traffic between server and client thereby decreasing latency
- Increasing responsiveness of your web apps by localizing access to more relevant data set
- Distributing the load from a single, server side controller to hundreds of browsers
The architecture at work here is very similar to CDNs - content delivery networks! Really it is about localizing data, and bringing it nearer to processing centers.
Having said this, you may continue to make exclusive use of one over another, if you understand the architectural needs of your product. Right tool for the right job.
Well, you are still going to need an initial page, which could be served by a server-side MVC engine.
Apart from that, client-MVC + REST could work, but I think in big applications you still have different sections and you need to tie these sections together. This would be possible doing it client-side, but I think it's easier to do that server-side.
For the moment I can see both coexisting happily. You could still do as much as possible on the client-side and through REST, but if something is not possible client-side, you still benefit from the server-side advantages of MVC
Comparing just MVC from one endpoint against the other is not very constructive. MVC is the structure of how you organize your code. It is a family of design patterns that helps you decouple your code and make it more maintainable. We want that always.
Everyone will agree that whether you build on the server or the client, you must have a good architecture with separation of concerns. There is no contest there.
The real and more important question is: Client side vs Server side rendering? Where do you want to generate your HTML views, on the server or the client? This a different question that is more concerned about page speed & UI responsiveness. Also, it has been answered multiple times in multiple places. Search ex: https://stackoverflow.com/search?q=client+rendering+vs+server+rendering
I think that MVC is a great pattern for simple web applications. However it doesn't really help when building modern and rich web applications like Facebook or Gmail. Take a look at this post for more reasons why not to use MVC:
http://dennis-nerush.blogspot.co.il/2016/04/should-we-use-mvc-for-modern-web.html
来源：https://stackoverflow.com/questions/16447443/client-mvc-vs-server-mvc