2

I have searched and searched but got no answers: How should the MVC pattern work?

So long I got two examples out of many similar ones: one of them suggests that the view should be updated by the controller, but the model is directly updated by the view, and another one suggests that the model should be updated by the controller, but the view should be updated by the model.

I have learned that the view should display content from the model fetched by the controller, and the model content would be altered by the view and updated by the controller.

guilherme.oc97
  • 431
  • 1
  • 3
  • 13
  • [Have you seen this?](http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference?rq=1); There doesn't seem to be a consensus; for me, the model does nothing, it is just data. The controller is the only one that does anything, and the view is the translation of the model to (and from) presentation. – Kenney Nov 21 '15 at 21:02
  • Have you tried [this?](http://www.asp.net/mvc). It should give you a good idea of what MVC is about. – Khaine775 Nov 21 '15 at 21:03
  • 1
    asp.net mvc doesn't have much to do with mvc besides the name :P @Khaine775 – PeeHaa Nov 21 '15 at 21:19
  • @Kenney So in MVC the `Controller` returns new `Views` instead of updating existing ones, and in MVP the `Views` are automatically updated by data from the `Presenters`? – guilherme.oc97 Nov 21 '15 at 21:25
  • That's unclear to me. I don't think that way. It all looks the same to me. They're 3 concepts that interact; some acronyms are a bit more limiting than others. In MVC, everything can talk to everything: you can connect it any way you like. Since it is fully interconnected, each aspect is present in the others. For instance, saying there is content (model: database), logic (controller: server side scripts) and style (view/presentation: html/CSS), doesn't prevent you from using controller logic in your Dynamic HTML (JavaScript), or in your model (stored SQL procedures). – Kenney Nov 21 '15 at 21:35
  • @PeeHaa What do you mean by that? ASP.NET MVC uses the MVC design pattern? – Khaine775 Nov 21 '15 at 22:10
  • It does no such thing @Khaine775 – PeeHaa Nov 21 '15 at 22:44
  • If it's not an implementation of MVC, then what is it? – Khaine775 Nov 21 '15 at 22:54

1 Answers1

3

It's been a year, and I got no answers. Maybe because the question is kinda opinion-based, or maybe because it didn't get much attention.
But ever since then I searched and studied more and more about best practices and design patterns, and now I feel confident enough to answer my own question.

Q: So, how should the MVC pattern work?
A: It should work the way you design it.

The MVC pattern defines three vital types of components: the Model, the View and the Controller:

  • The Model is what holds and manipulates the data you're working with: it handles persistence methods (writing/reading or CRUD) and has all the properties that your file/database table has;
  • The View is what displays the Model in a human readable way: it binds his visual components' values to properties of the Model;
  • Finally, the Controller is what notifies the View of changes on the Model, or notifies the Model of changes on the View: basically it's a sort of messenger, notifying two parts of each others' actions.

Now, how's the usual data flow of a MVC application?

  1. The user changes a component value on the view;
  2. The View queries the Controller about the value that the user passed;
  3. The Controller then notifies the Model that it wants data about the value that the View passed;
  4. The Model interacts with the database and gets the corresponding values (if they exist). After that, it notifies the Controller that it finished whatever it was doing;
  5. The Controller notifies the View that the Model has been updated;
  6. The View updates its' components accordingly, changing whatever values that may have changed.

That was only the reading flow, the writing flow is similar but a bit different:

  1. The user changes values on the View;
  2. The View sends those values to the Controller, saying that data changed and it should be persisted;
  3. The Controller notifies the Model about the data changes, and passes the message along;
  4. The Model then updates the database with the new/updated data, and notifies the Controller;
  5. The Controller notifies the View that the Model has been updated;
  6. The View displays a message to the user, saying that the operation was sucessful.

Now, when I first asked this question, I was with a Java-heavy mindset, so I wanted to know how would I go about implementing this in Java:

  • DAOs and Java Beans. You write the views and the controllers, but the models are split between data objects (Beans) and persistence objects (DAOs);
  • Java Beans with embedded persistence methods. You write the views, the controllers and the models. The models are Java Beans that have whichever persistence methods you need (the most basic ones being insert, select, list, update and delete).

So, my final answer is: There's a lot of correct ways of implementing the MVC pattern. But there's a series of guidelines you should follow if you want your implementation to be correct.

guilherme.oc97
  • 431
  • 1
  • 3
  • 13