Writing the user interface of a Windows system is way too easy. Every new version of Visual Studio makes the task simpler and simpler through wizards and tools of every sort. Code-behind files in both ASP.NET and Windows Forms, but also to some extent in Windows Presentation Foundation (WPF), seem to suggest developers not to waste their time with design and stratification of software. A plain old ADO.NET query right in the code-behind class of a page attached to the handler of a Click event does the job. And it's effective, and it's quick. And it just works.
More generally, we're not far from truth if we say that user interface facilities encourage developers to put in the presentation layer more stuff and code than it reasonably should. As a result, the presentation layer operates as a catch-all for logic of other layers, mostly the middle tier, but often also the data access layer. Is this really bad? And, if so, why is it all that bad?
I'm the first in line who just doesn't bother to place an ADO.NET query in the Button1_Click event handler of a code-behind class — if that page belongs to a temporary site or is destined to stay up and running only for short time; for example, an ASP.NET page that lives the three months around a user-group meeting. But even copycatting a Web site project that does the same few and well-known things, an approach that provides simplicity and time-to-market, isn't a bad thing per se. So feel free to make use of SqlDataSource controls, Linq-to-SQL, and plain ADO.NET stuff. All rigorously done right in the code-behind.
But for large, durable, enterprise-class systems, it's all another story.
Here, stuffing code in the presentation layer that logically belongs to other tier is a mortal sin. Presentation and model are to be neatly separated and classes with some embedded user interface are really hard to test efficiently and safely. Not to mention the risk of code duplication and the inherent difficulty to evolve and enhance the system providing different views of same model. The Model-View-Presenter (MVP) pattern can be a significant help to rationalize the presentation layer.
MVP assumes a data model, a view class and some logic to coordinate the display of information to the user. The data model represents the entities in play. The view class knows about the user interface elements and is ultimately responsible for providing a user-consumable view for the data model. Pushing data into the view is the main task of the presenter. The presenter typically holds a reference to both the view and the model. The view receives input from the user and fires events to the presenter. The view doesn't know about the model. It receives data from the presenter according to the details of a contract in place between view and presenter. That's it.
