DevConnections – MVP Pattern in Real World Enterprise Systems
This talk was given by Dino Esposito.
We currently have an implementation of MVC/MVP with ASP.NET on my team, and it’s completely different than the architecture Dino talked about. I always like seeing alternative ways of doing the same thing with architecture.
What is the difference between MVC and MVP?
The MVC pattern doesn’t define a clear architecture. It defines a relatively loose strategy for making 3 actors (model + view + controller) interact. It creates a separation of concerns.
The MVP pattern is MVC based on 3 facts:
- The view doesn’t know about the model, but receives DTO’s (Data Transfer Objects).
- The presenter ignores the technology behind the view.
- The view is mock-able for testing purposes.
With MVC, the controller holds a reference to the model and the view. The View holds a reference to the model and fires events to the controller. The model fires events to the controller.
With MVP, the presenter holds a reference to the model and the view. The view fires events to the controller. The model doesn’t know about anything.
Dino went through a fairly thorough example of how you could architect this, and ran some actually code that did reads/writes to a database. Here is the gist of it… For each page or form, you create an interface, which is your view. The page/form implements the interface. When the page/form loads, the presenter is created and passes in the view interface, which is a instance of itself (this). The page/form then calls initialize on the presenter. This will do all the initial work. The presenter will set the IView properties, which directly sets the page/form controls values. For this to be mock-able, the properties on the IView use DTO’s. So, instead of exposing a drop down list, it would expose a generic object that would be connected to the drop down list on the page/form. When an event occurs, the event subscription method will call a method on the presenter, and the presenter will handle everything.
Personally, I like the idea of hooking the events of the page/form up directly to a method on the created presenter. Otherwise, the event subscriptions of the page/form are pointless. All it does is call a method on the presenter. Nothing else.
Overall, I really like this architecture. I really don’t know the different between MVC and MVP before this talk, and now it’s clear. I think I like the MVP approach better.