What are MVP and MVC and what is the difference?

When looking past the RAD (drag - decline and also configure) means of structure interface that several devices urge you are most likely ahead throughout 3 design patterns called Model-View-Controller, Model-View-Presenter and also Model-View-ViewModel. My inquiry has 3 components to it :

  1. What concerns do these patterns address?
  2. Just how are they comparable?
  3. Just how are they various?
2303
2019-05-09 15:19:48
Source Share
Answers: 8

Both are patterns trying to separate presentation and business logic, decoupling business logic from UI aspects

Architecturally, MVP is Page Controller based approach where MVC is Front Controller based approach. That means that in MVP standard web form page life cycle is just enhanced by extracting the business logic from code behind. In other words, page is the one servicing http request. In other words, MVP IMHO is web form evolutionary type of enhancement. MVC on other hand changes completely the game because the request gets intercepted by controller class before page is loaded, the business logic is executed there and then at the end result of controller processing the data just dumped to the page ("view") In that sense, MVC looks (at least to me) a lot to Supervising Controller flavor of MVP enhanced with routing engine

Both of them enable TDD and have downsides and upsides.

Decision on how to choose one of them IMHO should be based on how much time one invested in ASP NET web form type of web development. If one would consider himself good in web forms, I would suggest MVP. If one would feel not so comfortable in things such as page life cycle etc MVC could be a way to go here.

Here's yet another blog post link giving a little bit more details on this topic

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

15
2022-07-08 14:55:36
Source

Model-View-Presenter

In MVP, the Presenter contains the UI business logic for the View. All invocations from the View delegate directly to the Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. One common attribute of MVP is that there has to be a lot of two-way dispatching. For example, when someone clicks the "Save" button, the event handler delegates to the Presenter's "OnSave" method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed.

MVP tends to be a very natural pattern for achieving separated presentation in WebForms. The reason is that the View is always created first by the ASP.NET runtime. You can find out more about both variants.

Two primary variations

Passive View: The View is as dumb as possible and contains almost zero logic. A Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead, the View exposes setter properties that the Presenter uses to set the data. All state is managed in the Presenter and not the View.

  • Pro: maximum testability surface; clean separation of the View and Model
  • Con: more work (for example all the setter properties) as you are doing all the data binding yourself.

Supervising Controller: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case, it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.

  • Pro: by leveraging data binding the amount of code is reduced.
  • Con: there's a less testable surface (because of data binding), and there's less encapsulation in the View since it talks directly to the Model.

Model-View-Controller

In the MVC, the Controller is responsible for determining which View to display in response to any action including when the application loads. This differs from MVP where actions route through the View to the Presenter. In MVC, every action in the View correlates with a call to a Controller along with an action. In the web, each action involves a call to a URL on the other side of which there is a Controller who responds. Once that Controller has completed its processing, it will return the correct View. The sequence continues in that manner throughout the life of the application:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

One other big difference about MVC is that the View does not directly bind to the Model. The view simply renders and is completely stateless. In implementations of MVC, the View usually will not have any logic in the code behind. This is contrary to MVP where it is absolutely necessary because, if the View does not delegate to the Presenter, it will never get called.

Presentation Model

One other pattern to look at is the Presentation Model pattern. In this pattern, there is no Presenter. Instead, the View binds directly to a Presentation Model. The Presentation Model is a Model crafted specifically for the View. This means this Model can expose properties that one would never put on a domain model as it would be a violation of separation-of-concerns. In this case, the Presentation Model binds to the domain model and may subscribe to events coming from that Model. The View then subscribes to events coming from the Presentation Model and updates itself accordingly. The Presentation Model can expose commands which the view uses for invoking actions. The advantage of this approach is that you can essentially remove the code-behind altogether as the PM completely encapsulates all of the behavior for the view. This pattern is a very strong candidate for use in WPF applications and is also called Model-View-ViewModel.

There is a MSDN article about the Presentation Model and a section in the Composite Application Guidance for WPF (former Prism) about Separated Presentation Patterns

2108
2022-07-05 20:49:51
Source

MVP is not always a circumstance where the View supervises (see Taligent is MVP as an example) .
I locate it unfavorable that individuals are still teaching this as a pattern (View accountable) in contrast to an anti - pattern as it negates "It is simply a view" (Pragmatic Programmer). "It is simply a view" states that the last sight revealed to the customer is a second problem of the application. Microsoft is MVP pattern provides re - use Views far more hard and also comfortably excuses Microsoft is developer from motivating negative technique.

To be flawlessly honest, I assume the underlying problems of MVC apply for any kind of MVP execution and also the distinctions are virtually totally semantic. As long as you are adhering to splitting up of problems in between the sight (that presents the information), the controller (that initialises and also controls customer communication) and also the version (the underlying information and/or solutions)) after that you are attaining the advantages of MVC. If you are attaining the advantages after that that actually cares whether your pattern is MVC, MVP or Supervising Controller? The only actual pattern continues to be as MVC, the remainder are simply varying flavours of it.

Take into consideration this very amazing write-up that adequately details a variety of these varying executions. You might keep in mind that they are all primarily doing the very same point yet a little in different ways.

I directly assume MVP has actually just been lately re - presented as a memorable term to either lower debates in between semantic chauvinists that say whether something is absolutely MVC or otherwise or to warrant Microsofts Rapid Application Development devices. Neither of these factors in my publications warrant its presence as a different layout pattern.

183
2022-06-05 18:45:45
Source

MVP : the sight supervises.

The sight, most of the times, develops its speaker. The speaker will certainly connect with the version and also adjust the sight via a user interface. The sight will certainly occasionally connect with the speaker, generally via some user interface. This boils down to execution ; do you desire the sight to call approaches on the speaker or do you desire the sight to have occasions the speaker pays attention to? It comes down to this : The sight finds out about the speaker. The sight delegates to the speaker.

MVC : the controller supervises.

The controller is developed or accessed based upon some event/request. The controller after that develops the ideal sight and also connects with the version to more set up the sight. It comes down to : the controller develops and also takes care of the sight ; the sight is servant to the controller. The sight does not recognize concerning the controller.

125
2019-05-16 20:44:21
Source

Also worth bearing in mind is that there are various sorts of MVPs too. Fowler has actually damaged the pattern right into 2 - Passive View and also Supervising Controller.

When making use of Passive View, your View commonly implement a great - grained user interface with buildings mapping essentially straight to the underlaying UI widget. As an example, you could have a ICustomerView with buildings like Name and also Address.

Your execution could look something similar to this:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Your Presenter class will certainly talk with the version and also "map" it to the sight. This strategy is called the "Passive View". The advantage is that the sight is very easy to examination, and also it is less complicated to relocate in between UI systems (Web, Windows/XAML, etc). The negative aspect is that you can not utilize points like databinding (which is actually effective in structures like WPF and also Silverlight).

The 2nd taste of MVP is the Supervising Controller. Because instance your View could have a building called Customer, which however is databound to the UI widgets. You do not need to think of integrating and also mini - take care of the sight, and also the Supervising Controller can action in and also aid when required, as an example with compled communication reasoning.

The 3rd "taste" of MVP (or a person would certainly probably call it a different pattern) is the Presentation Model (or occasionally described Model - View - ViewModel). Contrasted to the MVP you "combine" the M and also the P right into one class. You have your consumer object which your UI widgets is information bound to, yet you additionally have added UI - spesific areas like "IsButtonEnabled", or "IsReadOnly", etc

I assume the most effective source I've located to UI style is the collection of post done by Jeremy Miller over at The Build Your Own CAB Series Table of Contents. He covered all the tastes of MVP and also revealed C# code to implement them.

I have actually additionally blogged concerning the Model - View - ViewModel pattern in the context of Silverlight over at YouCard Re-visited: Implementing the ViewModel pattern .

35
2019-05-13 11:22:00
Source

Both of these structures intend to seperate problems - as an example, communication with an information resource (version), application reasoning (or transforming this information right into valuable details) (Controller/Presenter) and also display code (View). In many cases the version can additionally be made use of to transform an information resource right into a greater degree abstraction too. An example of this is the MVC Storefront project.

There is a conversation here pertaining to the distinctions in between MVC vs MVP.

The difference made is that in an MVC application commonly has the sight and also the controller connect with the version, yet not with each various other.

MVP layouts have the Presenter accessibility the version and also connect with the sight.

Having claimed that, ASP.NET MVC is by these interpretations an MVP structure due to the fact that the Controller accesses the Model to inhabit the View which is suggested to have no reasoning (simply presents the variables given by the Controller).

To probably get a suggestion of the ASP.NET MVC difference from MVP, look into this MIX presentation by Scott Hanselman.

21
2019-05-10 20:26:47
Source
  • MVP = Model - View - Presenter
  • MVC = Model - View - Controller

    1. Both discussion patterns. They divide the dependences in between a Model (assume Domain things), your screen/web web page (the View), and also just how your UI is intended to act (Presenter/Controller)
    2. They are rather comparable in principle, individuals boot up the Presenter/Controller in different ways relying on preference.
    3. A wonderful write-up on the distinctions is here. The majority of remarkable is that MVC pattern has the Model upgrading the View.
39
2019-05-10 20:11:51
Source

I blogged concerning this a while back, pricing estimate on Todd Snyder's excellent post on the difference between the two :

Here are the key distinctions in between the patterns :

MVP Pattern

  • View is extra freely paired to the version. The speaker is in charge of binding the version to the sight.
  • Less complicated to device examination due to the fact that communication with the sight is via a user interface
  • Usually watch to speaker map one to one. Intricate sights might have multi speakers.

MVC Pattern

  • Controller are based upon actions and also can be shared throughout sights
  • Can be in charge of establishing which watch to display

It is the most effective description on the internet I can locate.

443
2019-05-10 19:55:27
Source