One of the clear advantages of using the MVC pattern is that it encourages separation of concerns – it doesn’t enforce it by any means, but following the pattern results in a nice clean, maintainable, flexible solution. The architectural advantages of this are documented everywhere, but I also believe that it aids separation of concerns in another way – in the roles of the project team members.
In the past, when working with WebForms, as a .Net developer I would spend a large amount of time in the UI layer, adding user controls to .aspx markup, and trying to explain to the UI developer how the “cssclass” attribute worked, why elements where rendered differently at runtime than they appeared in the code editor etc etc. It all felt a bit wrong. Because we are using Asp.Net MVC, on my current project we can both work side by side on a feature without treading on each others toes. We can deliver quicker and we have less breaking changes. I don’t put .Net code in the UI mark-up and the UI developer doesn’t put CSS styles in .Net code.
On my current project, our UI developer didn’t join the team until after Sprint 4 – that’s 8 weeks of development without a proper UI in place. However, at the end of each of those 2 week sprints, we presented our application to the client as working software and planned out what we were going to do next, all the time, completely ignoring the UI. We were lucky in that our client understood and trusted us when we said that the UI would be designed and built without any impact to the underlying functionality we had already developed.
And, after Sprint 4, when our UI developer joined the team, we went from presenting an application that looked like an out-of-the-box Asp.Net MVC application you get in Visual Studio, to a rich, professional, fully branded website in the space of one two-week sprint. He was able to completely re-skin the entire UI using HTML and CSS (helped by the fact that we’re using the beautiful Spark View Engine) without me having to change a single line of C#. Now that’s what I call separation of concerns.