2

To be honest, I'm a student here, but I have seen many questions from teachers asking for ways to explain, and I have not found one for the MVP and MVC patterns.

My problem is, that I have studied these pages, I have written many tutorials and followed examples and even worked school projects with them, but I feel like I can't grasp the essence of these patterns. Every time I have to do something with them I become "slow" as if not understanding, probably, because I'm not understanding something.

So my question is, is there a good analogy or clear explanation to the MVP and MVC patterns individually and/or comparably?

  • A good analogy for MVC might be this: imagine a Person class holding data like name, address, phone number, username, and password. This is the model. Your view shows that person's name and username to the user, but not their address or phone number and certainly not their password as you don't wish to show everything. The controller is the button which when pressed allows you to edit that person's name and save it, which updates the model itself. Is that clear? – Neil Jun 20 '17 at 10:38
  • 5
    Forget about analogies, the question is: Do you understand what problems the patterns in question are trying to solve? This is the key to understanding. – JacquesB Jun 20 '17 at 10:40
  • 1
    I think @JacquesB touched on my problem exactly. I couldnt even verbally express that I have no idea what problems they try to solve, other than they generally want to separate what (and how) the user sees, and what actually happens(?) – Dragonturtle Jun 20 '17 at 10:47
  • And nice analogy, Mr @Neil , I will remember that! If you can elaborate with the MVP one too and write up an answer, I can accept it to this question, and make another one for exactly my problem (this is a more general question) – Dragonturtle Jun 20 '17 at 10:48
  • 2
    It's helpful to consider that all of the MV* patterns are essentially UI abstractions. Their sole purpose is to provide ways to decouple the UI from the rest of the program. – Robert Harvey Jun 20 '17 at 20:37
5

There are 3 main variants of the same basic pattern:

  • Model-View-Controller: The granddaddy of them all. Originally defined with Smalltalk
  • Model-View-Presenter: Variant created primarily to deal with the limitations of Windows Forms architecture. Suits technologies where the UI cannot directly bind to the model
  • Model-View-View Model: Variant created primarily to deal with Microsoft's XAML based applications (WPF, Silverlight, UAP). Subsequently adopted by a number of Javascript frameworks like Angular.

To understand the variants, it helps to understand the original architectural pattern, and how separated concerns. The truth is that all three variants agree on both the Model and the View, with differences in how you model control.

Model-View-Controller

The Smalltalk concept of a Model was something called a Domain Model. The key difference is that the Domain Model also has the methods that each object needs to do within the client's domain. Essentially it is the application without any UI.

The Smalltalk concept of a View was something that could bind directly to your model. Buttons would bind to a method, text boxes would bind to the setters/getters, etc. It would also bind to something called a Controller.

The Smalltalk concept of a Controller is functionality that is for the application in general. For example your menu items that have "Save" and "Load" options, etc. are bound to a Controller that in turn does things with the Model. The "Save" controller is an object that would take the domain root and serialize it to disk or something like that.

Web based MVC applications have something called a Controller that maps URLs to methods that interact with a Model and bind it to a view.

Model-View-Presenter

WinForms (Windows Forms Applications) and things like it don't have direct binding. There are several functions on a UI where changing the value on a combo box affects the state in other places.

Typically for this and later variants the model is more of a "Data" model. In other words it's just the properties that make up the data for your business objects.

The Presenter is the combination of an interface and an implementation. The interface is something the model knows about, so changes that originate from the model can update the view. The implementation knows about the view and works intimately with it. It handles the UI related changes that have to happen, and then uses a callback to let the model update itself.

There is always one presenter implementation with every view. The interface can be reused, but typically it isn't.

It's a lot of work, so most people don't use MVP. It is about the only way to make applications based on WinForms testable though.

Model-View-View Model

With XAML based apps, and most javascript single page app frameworks, we have the concept of binding directly to our model again. The Model and the View are very similar to the original MVC concepts, but most people use a simpler Data Model rather than the full Domain Model.

A View Model defines all the view specific properties and interactions, and exposes the model through a bindable property called "Model". That allows the model to be ignorant of UI concerns, but still allows the view to be as interactive as we want. The View can bind directly to the model, or to the view specific properties.

In practice there is usually one View Model per View, though in theory it's not necessary.


In conclusion:

  • MVC started it all.
  • Models represent your business data and logic in all three variants
  • Views represent what the user interacts with in all three variants
  • The primary difference is how the view interacts with the model
    • Controllers respond to the view and act on the model
    • Presenters act as a bridge between the model and the view when you can't automatically interact with it (i.e. binding).
    • View Models add a layer of view specific models that the view can bind to and interact with the model that way

Which one you actually end up using is really dictated by the technology you are using. All three enable you to test the application thoroughly without invoking a UI.

  • It's a common misconception that Winforms doesn't have binding. It does, but it's not often utilized because it's a bit unfriendly. Same with Webforms. – RubberDuck Jul 3 '17 at 18:21
  • I've used the binding for WinForms tables, but not every control has ubiquitous support like it does in WPF. In other words, it's baked in at the control level, not at the framework level. 3rd party support can be particularly inconsistent. – Berin Loritsch Jul 3 '17 at 18:26
  • 1
    Like I said, a bit unfriendly, but it's there. I even once started to build an MVVM framework for Winforms that utilized ControlBindings. github.com/rubberduck203/Rubberduck.Winforms – RubberDuck Jul 3 '17 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.