MVC Isn't About Replaceable Parts

My continuing thoughts on MVC...

We separate models, views and controllers, because it decreases the cost of change. It does not, however, allow us to replace one these layers without changing the others. That's rarely practical. If it happens, that's great, but don't count on it. The same thing is true in thin clients. It's a nice idea to think that you can redesign your site simply by replacing your CSS and leaving your markup and javascript alone. Unfortunately, that's usually not the case.

We decouple our systems along these lines because over time we've found that these particular configurations create effective firewalls to halt the ripple effects of change. A harbor doesn't prevent all waves from rocking the boats, it just makes the big ones smaller. MVC and it's ilk make maintenance easier by reducing the cost of change, not creating a plug-replaceable system. Plug-replaceable systems are expensive and difficult to create, and you should only make one if you need it for a specific business reason.

By extension, if your domain causes changes to frequently occur in other parts of the system, decoupling those parts from the rest will decrease the cost. And while I'm not going to tell you to forget MVC (or Model-View-Presenter, or any other paradigm), be sure that the separations you create actually insulate changes that tend to occur on your particular project, and aren't just there because you think they should be.

Comments

[Niels Bom]

I see it as being an ideal to strive for, with benefits increasing the closer you get to the ideal. As you say, attaining the ideal will probably be so costly that it won't be tried, but there's a sweet spot somewhere for every project.