CODEWITHSUNDEEP
model-view-controllerdesign-patterns
Nelson Tatius
Nelson Tatius

Reputation: 8053

Relations between elements of MVC

Can someone explain the relations between elements of MVC (with the active model), painted on this picture?

MVC

I see it like this:

  1. Controller → Model — a model's data changing by the controller.
  2. Model → View — the model notifies the view about changing.
  3. View → Model — the view get data from the model.
  4. View → Controller — the view notifies the controller about user's actions (for example, button pressing).
  5. Controller → View — but this relation, as I think, is unnecessary and contradict MVC rule about developing the controller independent from the view: it should interacts through the model.

Upvotes: 2

Views: 3040

Answers (3)

i8abug
i8abug

Reputation: 1682

As for the controller->view relationship you have highlighted

  • The controller needs to be able to choose the appropriate view that is displayed

AFAIK, that is the only relationship the controller has with the view (aside for the view routing messages to the controller). MVC is a little different from MVVM/MVP because you don't necessarily have just one view for each controller. For example, you could have a user controller and you might have a view for displaying information, one for editing users, and one for adding users. With the other two methods, there is a one to one relationship between views and ViewModels or Presenters.

  • Controllers being independent of the view is not a myth

Maybe I haven't used MVC enough in other scenarios but I have always kept the controller independent of the view. In fact if you have any view code in your controller (ie function with ListBoxEventArgs, referring to view components, etc) then you have not achieved the goal of this pattern which is to separate your view from your logic and model. I believe ASP.NET MVC makes views completely independent of the controller by having some class that manage tracking the initiated views. This class is available to all the controllers (through inheritance but dependency injection is fine too) and then each controller just picks a view to display using this class. The view can be selected with a constant or a string (in fact, I believe it is even possible to select them with no argument and based on the method name).

view->controller relationship

With ASP.NET MVC, view's are independent of the controller too since events are routed to the controller via url. However. in other non-web situations, it is fine to just forward your events to the controller by directly calling controller methods in the code behind.

Implementation details

On my blog, I wrote an article that covers the implementation of MVC a bit and should help answer your questions.

MVVM vs MVP vs MVC: The differences explained

Personally, I think the type of MVC shown in your diagram is not being employed as often today as in the past and it might be hard to find examples that use those relationships as shown. The reason is that if the view is able to talk to the model, then I think developers will opt for MVP or MVVM (and use a view model) over MVC. The only case I can think of where the view is not able to continuously talk to the model is in server client situations. In this case, there are many popular MVC frameworks like ASP.NET MVC is still popular today.

Upvotes: 0

kstaruch
kstaruch

Reputation: 1319

The MVC is rather broad subject, there are many variants of this pattern, and many implementations. I have seen solutions in which one of the responsibilities of a controller was to create an instance of a View with associated Model attached. This might be the relation you're looking for.

One other thing - existence of controllers independent from the view is a myth in real-life scenarios, in my opinion. Sooner or later you need to provide a functionality which explicitly tightens the View - Controller relation and is unusable (or simply different) without that particular View. Besides it is far more efficient to embrace the fact that different types of views behave differently and turn this into advantage by building tailored Controllers instead of pretending that we could deal with every aspect of user interaction with just one.

Upvotes: 1

Vince V.
Vince V.

Reputation: 3143

I think the relation between the between the model and view is wrong (at least the solid one). The way I see it in an MVC pattern is that everything goes via the controller. So in the view, the user selects the data he wants to see.This request is send to the controller. The controller is going to get the data in the model and the model gives back the requested data. The controller then sends it back to the view and the view outputs it to the user.

Upvotes: 0

Related Questions