I just had another very interesting and insightful discussion about the benefits and disadvantages of content, presentation and behavior separation (or, if you're more familiar with it, the MVC paradigm).
We all know what horrible abominations can be created when no separation exists and no plan is followed. We've all seen PHP code. The more frail of mind among us still have nightmares. The most stubborn still battle the language and try to invent a set of rules and policies that would make it usable. Others just called for the cavalry of other languages: SQL for the data and various templates or widget libraries for the presentation – after all, what can mark a border between different parts of a program more profoundly than a change of language it is coded in?
Alas, are borders really so clear cut? Are they really required? If so, are they required exactly in this form? If not, what is required to prevent your code base becoming a shambling mass of horror? I feel I might be getting to something that may resemble an answer – a vague one. Let me explain how I see it.
It's no secret that different activities involved in creating a non-trivial application (or, really, any non-trivial construct) require different sets of skills, knowledge and approach. This obvious fact results in different people being good at different parts of the work. But it's not only people. Many tasks are best performed when in a specific frame of mind – some require a great dose of concentration and attention to detail, others beg for wide view of the whole project and "feeling" it, yet others will be best performed by people who can force their mind to work like that of a "normal user" (the original normal user is kept under a bell jar in a vault in the ISO Institute in Geneva). This basically means that some work is best done by different persons, or by the same person but at different time. It applies both to large projects with numerous teams, and to small, single-person endeavors.
It is natural to split your project into parts that correspond, at least vaguely, to the areas of expertise of members of your team and/or to frames of mind or methodologies that are required to successfully finish them. You can't really expect a programmer to hack code and write user manual at the same time – either one or the other (and most likely both) will be of suboptimal quality – or the programmer dies of effort.
Enters the Model-View-Controller separation – or, if you're more into web pages or documentation – the Content-Presentation separation. These are paradigms, design patterns , advices or even hard rules enforced by project managers. They sound very nifty and cool, and indeed what can be simpler to follow that a three-word rule? But the problem is too complicated to be described with three words. Sure, everybody can quote examples of what is clearly model and what is clearly view, and how controller binds them together. Or was it the model binding together the view and the controller? Never mind. So ask anybody what is MVC, and he will immediately start showing you those old, worn out examples. But ask him about a specific, real-life case. Which part does this particular element belong to? Most likely you will only hear an arbitrary decision (and different from every expert you ask) or be dismissed by some hand-waving. So, you are given this advice, and are generally frowned upon if you request clarification.
The truth, as scary as it may look, seems to be that there is no hard division between content and presentation, or between model, view and controller, except for several special cases that are quoted all over the books. So, are we condemned to PHP-like code for the eternity? Is there no hope?
Nay! Don't give up hope! There is a way! Look, we can just do the same thing those smart book writers did when they created the term MVC. We can identify the parts of our project that require different approaches or are best handled by different members of our team. Voila, our own, custom-built MVC. You see, it's not about what the certain part really is. The presentation may as well be content, and the model may model behavior. The important thing is who deals with them and how he does it. Differences in tools used, in documentation needed, in concentration required and, obviously, in staff involved (and in their reuse, which I didn't mention) – all warrant a division in your project architecture, a division that will prove advantageous in the sheer amount of work it saves you coordinating all the efforts.
So, where did the original presentation-content distinction came from anyways? Well, you see, for a success of your project, you must consider not only your team members – you must also take into account the users of your system. Consider them members of your now extended team. Do you see? Of course! The work they do requires different skills, knowledge, frame of mind and personnel than the work you do. And once the product is shipped, you really want to minimize the interactions between those two groups – mostly because they tend to be costly. So here appears that magic "presentation" – what you do, and "content" – what your users do. But beware, as this is often overly simplistic. For example, your users might be themselves separated into several groups, with varied needs and difficult inter-group communication. If they are, your MVC might turn into MVCERPACFQWERTY, for example, whatever that acronym might mean.