Blog Stats
  • Posts - 18
  • Articles - 0
  • Comments - 14
  • Trackbacks - 82

 

Model-View-Presenter split into two "new" patterns

For the past year or so, Martin Fowler has included the pattern Model-View-Presenter, or MVP, in his upcoming addendum to  Patterns of Enterprise Application Development.  Due to apparent confusions between MVC and MVP, Fowler has now split this pattern into what he's calling “Passive View” (http://martinfowler.com/eaaDev/PassiveScreen.html) and “Supervising Controller/Presenter” (http://martinfowler.com/eaaDev/SupervisingPresenter.html).  (Now what am I to do! ;)

Passive View stresses zero/none/nada dependencies between the View and the Model.  Previously, with MVP, the View could be given a dependency to the Model to decrease the amount of communications between the View and the Presenter.  But, from how I understand it, the Controller in Passive View (previously the Presenter in MVP) would now have a dependency on System.Web, in ASP.NET anyway, to facilitate direct communications with the View display elements.  A “Test Double“ could then sit in for the View for unit testing purposes.  Although I really don't like the idea of a controller depending on System.Web, Passive View seems a bit simpler than MVP.  But instead of it depending on System.Web, Fowler suggests the use of a “Gateway“ to avoid the dependency.  The primary disadvantage to Passive View, in ASP.NET, is that it would become much more tedius to bind to a webcontrol, such as the datagrid, if the View has no knowledge of the Model.  I suppose DTOs could be used in their stead.

Alternatively, Supervising Controller looks to be a “flexible” interpretation of the original MVP pattern.  I.e. the View isn't completely dumb and knows how to use a limited amount of the Model.  Supervising Controller leaves the data binding up to the View and only helps out when the logic becomes non-trivial.  I believe this is very similar to how I discussed MVP to be in http://www.codeproject.com/useritems/ModelViewPresenter.asp.  The primary benefit to this pattern is that it makes the presentation logic easy to unit test.  The primary drawback, in my opinion, is that it makes it difficult to draw a clear line between what should go in the View (the code-behind in ASP.NET) and what should go in the Supervising Controller.  Passive View makes the separation of responsibility a bit more clear.

Now off to go update my class PPTs.

Billy


Feedback

# re: Model-View-Presenter split into two "new" patterns

Gravatar Billy, I was going to comment on your example on Code Project along the lines of what you are discussing here. I enjoyed your article lots and it gave me some ideas.
One thing I noticed, however, was the dependency of your presenters on your DAO pulling in your domain objects directly. I use a Service layer on top of my domain and allow my Presenters to only access my domain via that layer, kind of like the example from jeremy you have linked in your other writings on MVP. This dependency may not be a big deal in smaller apps or for consumers of domains that aren't very complex, but having data access in the presenter layer seems to muddy the presenter's roles. It seems like having a service interface your presenter/controller/whatever is interacting with will allow changing the view strategies (like from superivising controller to passive view).
Finally, I himmed and hawwed (Oklahoma expression) about whether to use DTO's or not and eventually decided to use them despite the Hibernate in Action's suggestion against them. I know they are a kind of anti-pattern and they are a bit of a hassle but provide a clean way to standardize messages from the domain/service layer and protect my domain from client abuses.
I'm newer to MVP than you are but thought I'd throw my two pennies in. 7/20/2006 8:33 AM | Mike

# re: Model-View-Presenter split into two "new" patterns

Gravatar Thanks for the comments Mike. Your service layer suggestion sounds interesting. Do you know of other resources, besides Jeremy's, that may explain this approach a bit more?

Thanks,
Billy 7/20/2006 8:43 AM | Billy

# re: Model-View-Presenter split into two "new" patterns

Gravatar Fowler's PoEAA book has a detail on p133, "Service Layer". Also, check out Session Facade in Java writeups (like Sun). Larman talks about it in his Applying UML and Patterns book as well. Basically, it's an interface that provides the contract for interactions with your domain and allows the indirection to keep the clients totally independent of the domain. I implement these as Singletons but you can DI these objects as well for greater flexibility and testability.
All clients consume your domain through this THIN layer. THere shouldn't be business rules in this layer (usually) although it looks like some folks put application rules here (as opposed to DOMAIN logic). When you abstract all this away from consuming your domain directly, you can move the parts of your app around alot easier.
For example, I had a complex server control that I wanted to use but I had totally refactored the domain that the control interacted with and changed the way items are updated and so on. Since I am joining my presenter to the IService interface and since my DTO's shield the complexity of the domain objects I was able to update my control within just a little time. Hope this helps. 7/20/2006 9:13 AM | Mike

# re: Model-View-Presenter split into two "new" patterns

Gravatar Thanks for the extra info Mike...I'm looking forward to trying this out.

Billy 7/20/2006 11:07 AM | Billy

# re: Model-View-Presenter split into two "new" patterns

Gravatar Man, just when you think you have it nailed. I'm really groking the MVP thing and finally got it. The big issue for me was the fact that I had a strong coupling between the Presnter and my Model, however as mentioned you can use a service layer (maybe with dependency injection?) so as to separate it.

I'm just trying to see what Fowler's getting at with his Passive and Supervising Controller, but I still think there are easier variations on MVP. You mention the controller makes MVP easier, but I disagree and the fact that it has a direct reference to System.Web means I have to have different controllers for different interfaces. Not a good plan in my books. With current implementations of MVP, my Presenter (Controller) and View know nothing of user widgets which makes testing and portability easy for me.

But maybe that's me. Need to do more research and testing to figure it all out. 7/24/2006 10:31 AM | Bil Simser

# re: Model-View-Presenter split into two "new" patterns

Gravatar I agree about the System.Web reference...I *really* don't like my presenters/controllers knowing anything about System.Web...really! ;) Honestly, I don't see much difference between the previous MVP definition and Supervising Controller...so I'll just rename the layer MyProject.Presenters to MyProject.Controllers and I think I should be up to date with the latest Fowlerology.

Billy 7/24/2006 11:18 AM | Billy

# re: Model-View-Presenter split into two "new" patterns

Gravatar Hi Billy, thot you might want to see this article...he is implementing a service layer and DTO's. I arrived at a similar framework and have found it to work great!
http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx 7/27/2006 5:22 PM | Mike

# Podcast:: Design Patterns Bootcamp: Model View * Patterns

Gravatar Design Patterns Bootcamp: Model View * Patterns Listen to the Show! Thanks to Dave Bost for the intro! 3/8/2007 10:16 AM | Polymorphic Podcast

# Podcast:: Design Patterns Bootcamp: Model View * Patterns

Gravatar Design Patterns Bootcamp: Model View * Patterns
Listen to the Show!

Thanks to Dave Bost for the intro!... 3/8/2007 10:18 AM | Craig Shoemaker

# re: Model-View-Presenter split into two "new" patterns

Gravatar HI, You can read more about the MVP split in
http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html 9/18/2007 5:27 PM | Ori

Post a comment





 

Please add 1 and 2 and type the answer here:

 

 

Copyright © Billy McCafferty