Lately I've been doing a lot of research on design patterns for web application development, specifically in the Microsoft ASP.NET technology space. This has led me to thinking a lot about how the developments of the past can better refine Zend's promising future. I find it of particular interest that Zend has made a conscious effort to deviate from enforcing a particular design pattern. In the original release candidates of the Zend Framework, it appeared as though MVC was the only way to go. Luckily, this is no longer the case, and crafty developers have found creative ways of implementing patterns that encourage testability and larger code bases.
What seems to have been a requirement for contemporary Ruby / Python / PHP developers has really hit home with the C# web development community. It seems that two camps within Microsoft are pushing MVC (Model-View-Controller) and MVP (Model-View-Presenter) separately and simultaneously. On top of that, the confusion is being fanned out on blogs rather than through official testimonies from Microsoft. Developers are now stuck doing a ton of research with the hopes that one of these patterns will lead to "best practices" for the future.
I've listed out the three ASP.NET development approaches I've recently encountered.
- Codebehind development - this is the 2.x and 1.1x ASP.NET development model. Essentially the events and the business logic are stored in the code-behind. A lot of developers using ASP.NET still develop using this approach since the pre-compiled user controls lend themselves to direct data binding.
- Patterns & Practices MVP - The Microsoft Patterns & Practices group have been development application blocks, essentially, these are high-level development libraries that encourage developers to invest more time writing business-specific code. The application blocks that I've found particular cool are Validation, Logging and Exception Handling. This same group has been pushing "guidance packages", a bunch of recipes that facilitate a module-based development paradigm.
- MVC ASP.NET - Scott Guthrie, lead developer on the original ASP.NET architecture has been pushing for an MVC framework that closely resembles Zend and Rails.
Interestingly enough, the last two pattern approaches infringe on a lot of independent development.
In terms of a working MVC approach, Castleproject's Monorails has been a working implementation with a strong community for some time. However, now that Microsoft has decided to re-engineer this pattern, only time will tell if the Monorails community will be forced into jumping ship; a sad reality that developers in that community have been frequently faced with.
Phil Haack (Blog), Jean-Paul S. Boodhoo (MSDN magazine 2006), David Hayden (Blog) and Billy McCafferty (Codeproject) have all offered up sample projects around the MVP paradigm. While all of them are absolutely fascinating to the nerdy developer, they all quietly omit validation and how it affects how events fire on a page.
The MVP pattern, while being an evolution on MVC, seems to shine when unit testing is at the core of the development approach. Furthermore, because of the event-driven model, the presenter seems like a logical place to begin development. Mocking frameworks like NMock and Ayende's RhinoMock facilitate the isolation of a real persistence layer from DTO's (Data Transfer Objects) being pushed up from a Repository.
Microsoft seems to have missed the boat in the Patterns and Practices group for three reasons:
- The PnP tests that come with the sample projects incorporate methods that encourage the instantiation of a full-stack web server. This approach fundamentally breaks the notion of a Separation of Concerns since the presenter should be fully working without a web server.
- MVP really shines when TDD is applied to the development of the Domain, however with the recipes in place, a developer is more likely to start with a recipe and flush out code for the Presenter directly, essentially falling back on a waterfall development approach.
- The MVP sample circumvents the ugly fact that user controls have become too intelligent. Web Controls in ASP.NET implement appearance, events, data and validation. Luckily in ASP.NET 2.0, appearance has been isolated through the use of Skins, however events, data and validation are still managed in a similar manner. MVP, as I understand it, dictates that events are managed by the presenter, however the MVP sample projects attempt to hide the uglyness of the high-level data binding in Controllers! How could the terminology for these patterns become anymore confusing?
Welcome ASP.NET MVC
What appears to be a Microsoft implementation of Zend / Rails seems to have missed out on the issues that lie dormant in the MVC pattern that MVP has attempted to address.
Where does validation go?
Validation is a terrible word. It refers to data integrity at the persistence level, it refers to user submissions, security contexts and sometimes it's confused with business rules. All of these are different concerns that a web application has to deal with and to be honest, I haven't found a pattern that even attempts to handle all these different aspects of validation in a coherent, systematic and discrete manner.
How are business rules delegated?
Business rules belong in the domain of an application. The issue here is that business rules, being specific to a business, don't really fit into the typical "lets make a blog application in 10 minutes" approach to development. They are crafted in an iterative manner through discussions with the client, and as such, they also tend to disappear from any sample patterns or applications I've come across.
How should you handle AJAX calls to a controller?
My own thinking here is that a presenter architecture shouldn't care whether the event fired is from an AJAX request or a POSTback on a form. The IView should be passed in with the event firing and so the modifications that the presenter handles can be localized to the interface it receives.
I find it particular curious that the developers in PnP have decided to omit their own implementation of the Entlib Validation Framework in their MVP project. Ultimately, I think that Fowler might have been onto something when he said that MVP should be split into two separate patterns, Supervising Controller and Passive View.
Technology aside, I think Derek Greer has put together a fantastic history of MVP and MVC that's worth looking at, regardless of which technologies you're advocating and which patterns you've been committed to implementing.
If anyone out there has answers to these questions, I've been searching hard to come up with a good implementation of these concepts, regardless of economic interest.
{ 1 trackback }
{ 0 comments… add one now }