Model View Presenter (MVP) – Tips from trenches (TFT) – Announcement
I have blogged already in the past about MVP basics, MVP vs MVC, MVP Passive View and MVP Supervising Controller but recently I had some interesting experiences in applying MVP into real world applications and from that endeavor I learned couple of things and get answers on couple of common questions which I would like to share with community.
To me, the most interesting part of this experience was that some of my MVP based coding was done using Web Client Software Factory but part of MVP coding was done without it, so I had to “port” WCSF features to standard asp net application. I would describe pieces of that port which (I guess) would be interesting for the ones not being able to sell WCSF to their managers but still wanting to use MVP in their ASP NET development.
Another thing I would try to explain is something a lot of people don’t know: Microsoft MVC .NET framework consist of two separate parts: MVC and routing engine. In other words, routing engine is not part of MVC design pattern and it can be used with WebForms too…
Another very important thing in real world MVP development I would try to demo is how to introduce MVP pattern usage in legacy components where the legacy model is not written in decoupled manner (Separate interface, Adapter and Translator design patterns)
Last, but not the least, I would show how MVP pattern is looking combined with ServiceLocator I presented in Design For Testability blog post series and show examples on how to test MVP
Once I finish presenting all this, I would use presented concepts in showing how “one interesting "real world" example” would look like done with MVP pattern and standard WebForms
So, MVP fans stay tuned for the posts to come very fast. People not interested in MVP, please be patient… I just need to nail down MVP , “once for all” 🙂
Disclaimer: The purpose of this blog post series will not be showing that MVC based web development is worst then the MVP one. MVC is awesome but unfortunately requires too big investments to be introduced in existing large web forms web applications (most noticeably the need for redesigning all code which relies on page event life cycle). For those brownfield scenarios, I found MVP much easier to be implemented and adopted by webform developers then the MVC.