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.