Model-View-Controller (MVC) is a widely used software design pattern that was created by Xerox PARC for Smalltalk-80 in the 1980s. More recently, it has become the recommended model for Sun’s J2EE platform, and it is gaining increasing popularity among ColdFusion and PHP developers. The MVC pattern is a useful addition to a toolkit, no matter what language you choose. But among its many benefits, it does have some drawbacks.
How MVC works
MVC is a design pattern that enforces the separation between the input, processing, and output of an application. To this end, an application is divided into three core components: the model, the view, and the controller. Each of these components handles a discreet set of tasks.
The view is the interface the user sees and interacts with. For Web applications, this has historically been an HTML interface. HTML is still the dominant interface for Web apps, but new view options are rapidly appearing. These include Macromedia Flash and alternate markup languages like XHTML, XML/XSL, WML, and Web services.
Handling all of these interfaces in your application is becoming increasingly challenging. A big advantage of MVC is that it handles the use of many different views for your application. There’s no real processing happening in the view; it serves only as a way to output data and allow the user to act on that data, whether it is an online store or an employee list.
The next component of MVC, the model, represents enterprise data and business rules. It's where most of the processing takes place when using MVC. Databases fall under the model, as do component objects like EJBs and ColdFusion Components. The data returned by the model is display-neutral, meaning that the model applies no formatting. This way, a single model can provide data for any number of display interfaces. This reduces code duplication, because model code is only written once and is then reused by all of the views.
Finally, the controller interprets requests from the user and calls portions of the model and view as necessary to fulfill the request. So when the user clicks a Web link or submits an HTML form, the controller itself doesn’t output anything or perform any real processing. It takes the request and determines which model components to invoke and which formatting to apply to the resulting data.
So, to summarize, a user request is interpreted by the controller, which determines what portions of the model and view to call. The model handles interaction with data and applies business rules and then returns data. Finally, the appropriate view is determined and formatting is applied to the resulting data for presentation.
Why you should MVC
Most Web applications are created with procedural languages such as ASP, PHP, or CFML. The initial temptation is to mix data-layer code, such as database queries, in with your display code, which is usually HTML. Separation of data from presentation is something that most experienced developers strive for, but often, this emerges out of trial and error and not a deliberate plan. MVC enforces the separation of these portions of an application. While it requires extra effort up front to architect an MVC application, the payoffs are impressive.
First, and possibly most important, is the ability to have multiple views that rely upon a single model. As I mentioned, there's an increasing demand on new ways to access your application. A solution to this is to use MVC. With MVC, it doesn’t matter if the user wants a Flash interface or a WAP one; the same model can handle either. Code duplication is limited because you’ve separated the data and business logic from the display.
Because the model returns data without applying any formatting, the same components can be used and called for use with any interface. For example, most data might be formatted with HTML, but it could also be formatted with Macromedia Flash or WAP. The model also isolates and handles state management and data persistence. For example, a Flash site or a wireless application can both reply on the same session-based shopping cart and e-commerce processes.
Because the model is self-contained and separate from the controller and the view, it's much less painful to change your data layer or business rules. If you switch databases, say from MySQL to Oracle, or change a data source from an RDBMS to LDAP, you need only alter your model. If written correctly, the view won’t care at all whether that list of users came from a database or an LDAP server. The three parts of an MVC application are black boxes whose inner workings are hidden from the other portions. It makes you build well-defined interfaces and self-contained components.
The concept of the controller is also a benefit. To me, the controller is used to stitch together different pieces of the model and the view to fulfill a request. This places significant power into the architect’s hands. Presented with a number of reusable building blocks in the model and the view, the controller picks and chooses which blocks are needed to handle specific processing and display requirements.
Drawbacks of MVC
Among the drawbacks of using MVC is that it's not necessarily easy, and it is definitely not for everybody. MVC requires significant planning. And it introduces a deeper level of complexity that requires diligent attention to detail.
You’ll have to spend a good amount of time thinking about the way the parts of your application will interact. Also, the rigorous separation between the model and view can sometimes make debugging more difficult. Each piece will require thorough testing before it can be introduced. The silver lining here is that once a part is tested, you get to reuse it with abandon.
In my experience, using MVC also means having more files to manage than you would otherwise. This might seem obvious, since the whole point is to separate the three MVC areas, but the additional work of dealing with multiple files shouldn't be underestimated. Just keep it in mind.
The bottom line is that MVC is overkill for small applications and even many medium-size ones. The extra work is probably not worth it: Taking the time to lay down a complex architecture may not be worth the payoff.
Overall, a good approach to building software
The MVC design pattern is a well-established and compelling approach to building software. The tenants it lays out, like separation of content from display, might seem obvious. But by forcing you to isolate the model, view, and controller components, it really does make you rethink your application and put a lot of thought into the architecture. If you can handle the extra up-front work and the additional complexity, the MVC pattern can open up new levels of robustness, code reuse, and organization.