The basics of MVC and MVP
Clear separation of responsibilities along with a low coupling level is a sign of a well-designed application. Whereas design patterns are proven solutions to reduce coupling between small sets of objects, architectural patterns help to improve a system’s design on the whole. One popular architectural pattern is Model-View-Controller. Originally came from Smalltalk now it has implementations in various languages. In Java for example such frameworks as Spring and Struts have gained high popularity and are widely used. However in .NET world the existing implementations aren’t much spread, being mainly inspired by Java implementations they fit well only for Web applications and are not suitable for Windows thick client applications.
Another architectural pattern that in fact is an evolution of MVC is Model-View-Presenter. The underlying ideas of MVP are very similar to those in MVC however MVP is designed to be more usable and understandable. MVP has much less implementations then MVC does, one known MVP implementation for .NET is the Microsoft User Interface Process application block (UIPAB). In spite of numerous problems, and hence low usability of UIPAB, its reasonable key concepts inspired us to create something new.
This article starts a series covering the development of a native Model-View-Presenter framework for .NET platform. Although it will be an MVP framework we will still use the term "Controller" as it seems to be be more pertinent than the "Presenter" notation (UIPAB follows the same manner describing itself as MVC, though in fact it is closer to MVP). Let us start with clarifying the basic concepts of an application’s structure. After that we will proceed to the discussion of the existing architectural solutions (including MVC and MVP).