Explain Model View Controller

Question

My experience with developing dynamic websites is limited mostly to Java servlets. I've used Tomcat to develop various Java servlets, and I wouldn't hesitate to say that I'm reasonably proficient with this technology, as well as with client-side HTML/CSS/Javascript for the front-end.

When I think "dynamic website", I think: user requests a URL with a query string, server receives the query, and then proceeds to output HTML dynamically in order to respond to the query. This often involves communication with a database in order to fetch requested data for display. This is basically the idea behind the doGet method of a Java HttpServlet.

But these days, I'm hearing more and more about newer frameworks such as Django and Ruby on Rails, all of which take advantage of the "Model View Controller" architecture. I've read various articles which explain MVC, but I'm having trouble really understanding the benefits. I understand that the general idea is to separate business logic from UI logic, but I fail to see how this is anything really different from normal web programming. Web programming, by it's very nature, forces you to separate business logic (back-end server-side programming) from UI programming (client-side HTML or Javascript), because the two exist in entirely different spheres of programming.

Question: What does MVC offer over something like a Java servlet, and more importantly, what exactly is MVC and how is it different from what you would normally do to develop a dynamic website using a more traditional approach such as a Java servlet (or even something older like CGI)? If possible, when explaining MVC, please provide an example which illustrates how MVC is applied to the web development process, and how it is beneficial.

Answer 1

First I think is best talk about what is MVC Architecture and then go further into the way you are currently programming.

The MVC Architecture is way to organize the workflow inside a sotfware sistem, think about it as a layered way to implement system behaviour. This layers are:

1. Model: Represents your Data Model, its the system core where all information related to it should be localized. So for example: if you are going to desing a Game you'll need Players, Rules, Obstacles, and some logic related to the interactions of this elements such as : Players should be able to sort Obstacles when some set of Rules apply.

   The Model is the first think you should think off because its going to be the center of your applications.

2. Controller: This is where the magic happens and where the Layered Architecture meets the Object Oriented Paradigm it was intended to use. Here is where you implement how does the system reacts when some application user request something about the app vai the user interface.

   The Controller should be able to handle the Model Objects, do operations with them to achieve what the user requested and then delegate the result to the corresponding View Layer to render it back to our user.

3. View: This is the Start and End Point of User interactions. Here is where you define how users interact with the application. Nowadays is quite common users try to access, for example, web applications from different kinds of media such as: Mobile Phones, Tables, Pcs, Laptops, etc.

   Generally each techonologie needs a diferent language to create the view, so imagine that your Data Model and the way that model interacts and how you render that interactions is all hardcoded, there is absolutely no way to reuse your code in a way that is not CopyPaste. The result is code that smells and lots of time wasted adapting the HOLE sysmte.

   The virtude of having the View in a separated layer, allow us to work independently from the Model we are currently working on. We only need to know how we should render the list of objects the controller is sendng us. How did he generated it is completly trivial

So , finally we got an independet Model that could be adapted as we see fit according to our current needs (today i need to handle a Monouser Game with no rules, tomorrow i whan to play with friends and now its Multiuser, and so on) that not depends on how are we going to render it to the user. Then, a Controller that captures users request that came from a view , process Model Objects, and then gives the information back to the View to render it.

Back to the first question you asked: Like you can see (i hope) MVC is a WAY to do things and not a TECHNOLOGIE to create software. You could use your java Servlets, and implement a MVC Achitecture under it.

Here is a Q&A example site using a MVC Architecture to clarify a little

Answer 2

To answer your question

What does MVC offer over something like a Java servlet

MVC is a pattern , not a technology . So the pattern can be applied when you are programming with Servlets too .

Let me try to explain MVC pattern with Servlets itself . So what you are trying to do when you talk about applying MVC is , separate the Model (the business logic) , the view (the presentation logic ) and the Controller (the controller Servlet which delegates the control to appropriate business logic) .

In this case, MVC is not about just separating business from the presentation layer and the controller layer , but the business layer does not even know that a controller or presentation exists .

Major frameworks in Java like Struts follow this pattern . I think you got the concept wrong . You can read more about it in the internet.

Answer 3

MVC is really easy to comprehend, it is just a design pattern, however, I've seen that the most difficult/overseen is the Model part.

• Model: Your data (not your database exclusively!, the model can even be an ini or xml file, or data from a web service). Model classes serve the purpose of defining, assembling, and handling data. Read the excellent article called "The M in MVC: Why Models are Misunderstood and Unappreciated". Model should be accessed only by the controller.
• Views: Your GUI (presentation) code. Should only access the controller
• Controller: Your logic. Handles the communication between model and view.

Answer 4

The Model-View-Controller concept is nothing new. It began with Smalltalk around 1979.

At it's core, MVC is a way to organize the responsibilities of your code so that it is modular, predictable, and robust.

The separation allows you the following freedoms:

• Ability to evolve the model without affecting application logic or displaying the data
• Ability to change business logic without affecting the model (i.e. add new steps, etc.)
• Ability to represent the model in multiple different ways

With care, you potentially can design the model and controller so that you can completely replace a desktop application with a web application as the front end.

More recently, the Ruby on Rails approach to MVC introduced some newer concepts that were copied in almost all MVC style web application frameworks. This included the concepts of "Convention over configuration", mapping controller actions to class methods, and routing URL requests to the underlying code.