MVC or MVP? Which design structure makes the most sense?

Question

What do you prefer? I looked at both, and there definitely is some inconsistency in what people call them.

I will try to write down what the differences are, and you can correct me if I am wrong.

MVC

• The model contains links to its own observers (Views); on model updates, it notifies observers.
• Views transmit all events and messages to the controller. Views update their contents when they are notified by the model that a change has occurred. View contains a link to the controller and model.
• The controller contains a model and (sometimes) views. Views will call the Controllers methods corresponding to user input, then the Controller then changes the model accordingly, and sometimes manipulates the View (blocks buttons on certain clicks, View, etc.).

MVP

• The model has no reference to the view. Only provides data abstraction for the program. The model does not refer to anything.
• As in MVC Views, call the appropriate Presenter methods based on user input. View has a link only to the presenter.
• The presenter has a link to “Views” and “Model”. When View calls a method in Presenter, Presenter manipulates the model and then manipulates the view.

I'm sure I understand how MVC works, just my understanding if MVP is kind of iffy. I really like MVC, but the only part that doesn't work well with me is that the model, which should only be an abstraction of the data layer, also contains references to Views and does an update. It does not make sense.

Answer 1

Martin Fowler offers MVC and MVP analysis , and Wikipedia MVP provides more links.

There are two questions for me:

1). How to live is a Model-View relationship? If the model changes dynamically, and View (s) must be updated to reflect this change in the model, then we have a classic MVC, and the model somehow notifies of the relevant representations of the changes. This style does not apply to classic web applications (such as those implemented in Struts). Here usually there is a view created as one of the snapshot of the Model (indeed, often on the DTO provided by the model). In many literature, web style is still called MVC.

2). When the user does "something", who is responsible for ineterpreting and act. In MVC, this is usually the job of controllers. MVP seems to allow more direct interaction with View to Model for this purpose (if I understand the Fowlers article correctly).

I prefer a clean separation of concerns - the MVC approach is what I think, but it might just be an introduction.

What should a person choose? As a rule, I think that you are guided by a framework which you decided to use. I come from the background of Struts, so for MVC for web-style I feel quite natural. If I understand correctly, MVP has an explicit acceptance in some aspects of .NET. I would go with the flow of any structure that you have chosen, and I would not give up the structure just because it is MVP and not MVC, even if we assume that a clear distinction can be made.

Answer 2

What about MVVM? (Model View View-Model) In this style, the model does not contain references to the view and vice versa. I will not pretend that I know a lot, because I am just starting to study it, but recently we made a choice to go to this design pattern, so I assume that he has some merits.

http://en.wikipedia.org/wiki/Model_View_ViewModel

Answer 3

In any template, the Model cannot depend on any other components. "Has links" only for Observer objects. It does not matter if these observers are species, controllers, or other models.

MVC is the most erroneous design pattern and has no real definition. I am going to use a book published by Martin Fowler.

Consider the UI / a CRUD / screen for a complex business object in a desktop application. (Struts as MVC is a little different). You have one model (business object), several views on the screen, each of which has its own controller.

The user interface logic (validation, inclusion of widgets related to a business object) is scattered across all View and Controller objects. In this sense, the MVC pattern is outdated (!), Although at that time the separation of problems was revolutionary and provided richer user interfaces.

In MVP, you have a model, a view that is dumb, all the user interface logic is inside the Presenter. Presenters will share View elements with action / event handlers / delegates. Thus, the view only accesses the Host when the user interacts with the corresponding widgets on the screen. The host acts as an intermediary, encapsulates the interaction of the widget.

I really recommend this link http://martinfowler.com/eaaDev/uiArchs.html . The whole MVC theme is not as simple as it might seem. This is almost a theory in itself.

Answer 4

Assuming my understanding is correct, the Model should not contain a reference to the view in MVP or MVC.

I will say this, but your definition of how MVC / MVP should be implemented may be slightly different from the following guys. I think that the template exists for the general idea of ​​separation of problems, but it can be adapted in order to exactly match the needs of a particular implementation.

Answer 5

I think it depends on the environment in which you are. In a web environment, the controller selects which view will be displayed as a result of the request. Before this happens, the controller checks to see if there are any changes to the model. In other words, the view does not need a direct connection with the model.