CODEWITHSUNDEEP
model-view-controller
guilherme.oc97
guilherme.oc97

Reputation: 451

How should the MVC pattern work?

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.

Upvotes: 2

Views: 297

Answers (1)

guilherme.oc97
guilherme.oc97

Reputation: 451

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.

Upvotes: 3

Related Questions