Clean Separation of Concerns in MVC
One of the main areas that is cited as a benefit of using the new ASP.NET MVC Framework is that you can obtain a 'clean separation of concerns'. But the question is, what does this really mean, how achievable is it in reality, and should we really be interested in doing it?
What does it mean?
Well, from Wikipedia (http://en.wikipedia.org/wiki/Separation_of_concerns) - 'the process of breaking a computer program into distinct features that overlap in functionality as little as possible'. The article goes on to say that the MVC design pattern aims to separate content from presentation and data-processing from content. This is all well and good, but where do the lines of separation fall. One is reasonably clear - between the data-processing (Model) and the rest of the application. Almost every attempt at writing an MVC Framework web application illustrates this successfully.
The slightly harder area to tie down the separation for is when you look at Views and Controllers. Where should the separation occur? What is the division of responsibility? Should the two portions be completely independent, or can they have knowledge of each other? At a certain level, it is reasonably easy to provide some definitions: the view takes responsibility for presentation, and the controller takes responsibility for actions. But there is clearly a grey area in the middle. Clearly most actions can be completed without much dependency on the view that is their 'end point', but the reverse is not necessarily true. In a simple 'display' view there is no problem, but by the time we move to 'editors', we are starting to get into the realms of some trickiness of definition. In fact the way the view is set up may have critical importance to the nature of the controller. This is probably best illustrated with an example. Let us say that I have written a appointment diary application. One of the editors in this is used to change the date of an appointment. I could choose to display this date in one text-box (DD/MM/YYYY format), or I could decide that it will be easier to use if I split it and put the day, month and year components of the date in different text-boxes. Either way, I have introduced a link between the way the data was displayed and my controller. If I change one way of displaying the date into another, I may need to change the controller, unless the view takes care of returning the date to the format from which it 'came'.
But here lies another problem - 'format from which it came'. It's perfectly legitimate in MVC that the View may have fetched the data it is displaying from the Model directly and that the Controller had no knowledge of the original form of the data at all. Either way, we are getting towards the situation where the Controller needs knowledge of at least one of the Model and the View in order to function. The problem really comes from the nature of HTTP. The View is split between what it was on the server, and what is able to be transmitted 'over the wire'.
So is full separation achievable?
Well, we could remove the requirement that the Controller knows things about the View. It would require something of a rethink to the way the MVC Framework is currently designed though. It would require that Views 'submit back to themselves', that the View can then sort out the data before triggering an appropriate Controller action. But there is a problem. We've essentially introduced a dependency that the View now needs to know about the Controller. So we're back to square one! I therefore don't think that the View and Controller having no knowledge of the structure of each other is practical. They are implicitly linked.
Where does that leave us?
Well, not all at sea, thankfully! And luckily, I think in considering what we really mean, we come to what really turns out to be a very good way of architecting an MVC web application. I believe that the separation is not a totally strict one of encapsulating all knowledge about the different portions of the code, but rather a clean separation between behaviours and views. Interestingly, this is one of the key points of object oriented design that is often overlooked - designing an application by the behaviours that it must be capable of. The REST-like routing system built into the MVC Framework as it stands takes you even further down this route of considering the application to be much like an object oriented design. Essentially therefore, Controllers can (in some sense) be likened to classes (and indeed this is the language construct they use!), and Action methods are the behaviours of which a Controller is capable. The big advantage of these Action methods being thought of as behaviours is that writing Unit Tests for them becomes a very natural process.
The conclusion of all of this is that there is going to have to be linking between your Controllers and Views. They can't be written to operate independently. The key point is to see the separation between behaviours and templates. Don't code things that are going to cause a change to the model into your View, and don't code things that are purely a matter of presentation into your Controllers, but expect a certain amount of grey area where the communication between them is concerned.