When is MVC not MVC? When it's MV of course.
Recently we've been working on a few projects (Progressive enhancement ) using the new ASP.NET MVC (Model-View-Controller) tools from Microsoft.
And actually we quite like them. In fact, we like them a lot.
For those not yet in the know, MVC is a pattern developed to isolate business logic and user flow. Microsoft have now released an implementation of the MVC that allows the use of this pattern on top (not instead of) its ASP.NET Web Forms offering.
--------------------------------------------------------------------------------------------------------
Model: In charge of data (updates databases, communicates with web services etc.).
View: Responsible for displaying the data and allowing client interaction.
Controller: Determines which View is displayed in response to an action.
--------------------------------------------------------------------------------------------------------
The framework has been a breakthrough for us as a company, particularly for internal projects. It's facilitated a closer inspection of the way we work and enabled us to balance the project workload more evenly between different teams, resulting in less downtime. It's also given us a great way of helping less experienced members of the team to develop new skills by encouraging a richer understanding of how the Server Side (C# and ASP.NET) interacts, assembles and eventually renders the page.
First things first, we used a mind mapping application to draw out the structure in terms of the Models, Views and Controllers of the solution so we all had a visual representation of the architecture from the start.
After a few days we found it was more efficient to break the workload up into two teams, which fitted our internal working practices better:
- Team A - Models/ Controller (database/ web-service integration and assembling the data.
- Team B - Views (CSS and JavaScript)
Of course, we do get brought back down to earth with a bump sometimes and have to run projects for clients who don't allow us to use the latest and greatest technologies the community has to offer. However, after reading through a specification from one of our clients that required integration with an existing codebase, it occurred to us that we just might be able to use the same methodology as we used with the MVC, with a few minor adjustments.
Best practice is common sense, but it's also interesting to shake things up a bit sometimes. So we took our new found love for the MVC, dropped the 'C' and started using an MV approach. The Controller seemed to add an extra level of complexity that wasn't strictly necessary as the page/View was already acting as the controller in this web form project.
Our goal was simple: use the MV pattern to create the models that could be used to drive the views in a way that allowed us to continue with our new MVC-based way of working.
After the initial project kick-off and design meeting, we began developing the interfaces for the models. Once we were sure we had the models down, we started creating some mock model objects.
As soon as they where mocked up, Team A and Team B started working on their allotted tasks. After a few days of hard graft - including the usual swearing and cigarettes - and half way through the allotted time, to our astonishment, we found that we'd completed the entire project.
We ended up with an easily maintainable, completely unit tested and timely project. Additionally the web forms weren't littered with various bits of data-access code intermixed with chunks of business and presentation logic...
Needless to say, we were all quietly impressed and treated ourselves to a couple of (extra) beers after work.
