Learning the MVP pattern…
MVP is a derivative of MVC, mostly aimed at addressing the "Application Model" portion of MVC and focusing around the observer implementation in the MVC triad. Instead of a Controller, we now have a Presenter, but the basic idea remains the same - the model stores the data, the view is a representation of that data (not necessarily graphical), and the presenter coordinates the application.
In MVP the Presenter gets some extra power. It’s purpose is to interpret events and perform any sort of logic necessary to map them to the proper commands to manipulate the model in the intended fashion.
I think I agree that MVP sounds better. In a typical Java MVC framework, M and V are clear enough, what’s C? In a Structs implementation, C are those terrible configure XML plus the action classes. RoR makes more sense, C are just "action" classes sitting by default under "controllers" directory. The action class invoke the model and render with a view. RoR don’t need those terrible XML definitions because it build on CoC (Convebtion over Configuration) philosophy.
In one of my past projects which using Structs, many confusing code was implemented inside the action classes, and some logic even sit inside the view(jsp files). In some case, the XML seemed not powerful enough to control all the flows, so some code in the Action class is doing something similar. Those made the project a mess. The lesson I learned from is, using a MVC framework don’t turn your project into MVC, the team need always think in MVC and implementation in MVC. The RoR is cool because it create things "on rails", its CoC sometimes force the programmer not easy to break some basic rules, and whole project framework was there and separated clearly so not that easy to mess it up.
MVC vs MVP: http://www.darronschall.com/weblog/archives/000113.cfm
MVP with ASP.NET: http://www.codeproject.com/aspnet/ModelViewPresenter.asp
The author of this great MVP article have an update "suggestion of MVC over MVP":
Specifically, MVP was a very powerful technique for writing ground-up, test-driven ASP.NET applications but is no longer a strong candidate for consideration when compared to the time saving benefits and simplicity of Castle MonoRail and Microsoft’s upcoming MVC framework. Oddly, it is sometimes difficult to "give up" on something that worked perfectly fine before, but that’s the nature of our business … one tenet that’s not likely to change anytime soon.
…
In summary, although I still believe that MVP is the best technique for developing ground-up ASP.NET solutions, I believe that there are off-the-shelf frameworks which make the entire job a heck of a lot simpler.
Design Pattern: MVP : http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/
MVC Pattern retirement notice: http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
Upon further study and reflection, I decided that pattern that was here under the name "Model View Presenter" needed to be split, so I have separated it into Supervising Controller and Passive View. You can find a discussion of the origins of Model-View-Presenter in the context of UI architectures here.
About
[...] I previously wrote some notes on this topic. [...]