My team and I are migrating a large web forms/ADO web application over to the MVC framework using nHibernate and Domain Driven Design principles. After dabbling in MVC and nHibernate (although I have used MVC in java in a past life) and reading Eric Evans' book, I've been chomping at the bit to implement these frameworks in our less than clean production code.
As I mentioned above, this is a large application and I am not about to suspend our feature backlog while we spend months converting web forms to controller/views. Instead I have decided to keep the current collection of web forms pages that we have now and "fold in" conntrollers and views as we build out new functionality. Any minor enhancements to existing web forms will remain in the current web form structure, but any changes requiring heavy lifting will warrant a conversion to MVC. I should note that our "model" is thankfully already abstracted into separate class libraries.
In order to accomplish this happy coexistence of web forms and MVC, we have done the following:
- Created a brand new MVC project for the views.
- Created a new project for controllers to keep the controllers and views separate (we are using the Sharp Architecture Framework)
- Added a "WebForms" directory to MVC Views projects
- Copied the web forms tree from our legacy web application project to the new WebForms folder
- Made minor changes to relative URL references
This has worked out really well for us. It has allowed us to keep a large and long lived application functioning as is while providing a framework for future functionality that is a much better enforcer of separation of concerns and far more unit test friendly.
We are taking a similar migration strategy with our Model layer. We have sevral class libraries of domain classes riddled with ADO code (yuck). Again, we are continuing to use these classes and extend them with small changes. However, large changes and new domain objects are following a DDD approach using nHibernate. There has been a definite learning curve with nHibernate and Fluent nHibernate, but I can't tell you how much cleaner the code looks without all of the database plumbing. You see only what you need to see -- your business logic not to mention we are no longer having to create countless stored procedures for the simple CRUD functionaity.
I don't think this architecture is suitable for every application. It would most likely be a poor choice for our external web application that serves over ten million page views a day. But it is ideal for a large administrative CRUD application supporting a complex domain model -- a perfect candidate for DDD.