[ Why is MVC used on the server? Isn't it a client-side pattern? ]
I'm trying to learn web development.
I understand (mostly) the concept of MVC, but I'm confused about why an MVC model is used on the server side...like Spring MVC. Isn't the server side the Model and Services, and then the client side Services, View, and Controller (AngularJS even makes that pattern explicit on the client side)?
I'm really struggling with how the MVC model fits into or facilitates server-side development.
Answer 1
MVC is a pattern used by much more than just web applications. Any app with a UI could use an MVC pattern.
The idea is that you have a View (html, or a window in your OS, or even a report or something), and you have a model that represents the dynamic parts of that view. Then you have a controller that is dedicated to processing input and doing the "business logic" to generate the model and apply it to the view.
So.. for example on the Server you might have this MVC pattern:
- A controller receives the HTTP request and processes it.
- It builds a model
- The model is applied to a view to generate HTML and send it back as a response.
On the client it will be similar (but a bit different in Angular's case):
- A controller is used to determine and manipulate the model.
- The model is then bound to your view via directives. (Angular is really more of an MVVM pattern, but it's similar enough)
- The view is similarly bound to your model via directives. (this is where the MVVM part comes in).
- The idea here is that both the model and the view are kept up to date by directives.
- The controller just contains "business logic" for manipulating the model.
Clear as mud?
No worries. Just know this: It's just a common pattern. It's not "server specific" or "client specific". It can be used anywhere by anything requiring data to be scrubbed into templated output.
EDIT: More thoughts.
In the case of a Web API that serves up JSON (or even XML) on the server, you're still using MVC in most cases. This is because what you're doing is:
- Process the request in a controller.
- Build up the model in the controller.
- Render the model to a "view", which in this case is a view that serializes it out as JSON.
Answer 2
In the good ol' days of yore, the client side was only a display. The server was responsible for communicating with the model, applying business logic, generating a view, and sending the static, rendered content back to the client (browser).
As the web matured, some of those responsibilities migrated from the server to the client. Now, the server-side is often a thin layer like RESTful API that stores the "official" business logic (rather than convenience logic on the client) and stores the model. But for performance and user experience, the client now stores a copy of the model in its own model layer, communicating with the server and/or local storage as necessary, and having its own controllers and view logic to provide an awesome user experience.
So does MVC still apply on the server? Yes! It's just different. The server often generates the initial view from which the client-side application runs (taking localization or internationalization into account, for instance) and still houses the official model. But more importantly, the "view" in MVC just changed. Instead of the server-side view being HTML, it's now JSON or XML that the client application consumes instead of just renders.
So for functionality's sake, we still use MVC on the server. But for an awesome user experience, we use MVC on the client-side now too.
