Mixu's blog

MVC, Model-Controller-View, is all the rage in web development these days. With regards to MVC, I think the right question is to ask not whether you should use an MVC framework but rather which framework fits the kinds of problems you are likely to encounter while developing your web application.

MVC frameworks: full stack vs. glue frameworks

There are the two basic options with MVC frameworks: glue frameworks and full stack frameworks.

1. "Glue frameworks" are collections of components and libraries which you can use to build an application. Most of the functionality is optional and often you must make decisions regarding how you will structure control flow within your application.
2. "Full stack frameworks" are integrated sets of components in which most of the components and libraries are mandatory and most of the design decisions have been made for you in advance.

Most frameworks are optimized for the 0-3 month project. All the basic functionality you need is there, but the expectation seems to be that you are creating a custom version of a blog or a CMS and that the most complex bits will be the views (custom code) and the models (posts, users, tags, comments). However, the more you're dealing with complexity with regards to business logic, integration, regulatory validation and scaling requirements, the more likely it is that a full-stack framework will require manual optimizations and supplementary mechanisms which are not easily implementable in a full stack framework.

Here is one example of how a full stack framework can end up in more complexity than a glue framework. In CakePHP (a full stack framework), if you want to show multiple "flash" messages, you have to rather actively work around the existing mechanism, because it does not support multiple flash messages easily. Yes, you can set one message per action and you can set custom styles, but setting more than one message becomes unnecessarily complex (see this article and have a look at the comments as well) because by default, the Session flash messages overwrite each other rather than appending to the existing set of messages.

This is a very trivial example - and you can use the existing Session classes to create most of the functionality necessary to fix this. But if you do that, you will end up with two "flash" message functionalities: the default one and the one you built to make it easy to set more than one message of each type.

A glue framework might offer the Session functionality without directly supporting flash messages. This does mean that you have to write your own, but you'll end up with a slightly simpler codebase. These kinds of small things add up if you have a larger project.

Now, the key question to me when deciding which to use is:

What kind of complexity/problems are you tackling in your application?

The optimal choice of framework depends on covering the 80% case effectively (without compromising constraints like performance).

Here are some questions to consider when picking the right framework for your project:

1. Complex views - What are the most probable uses of the system? Make sure you can cover the technical functionality needed to implement the most important client goals in a way that delights or at least does not annoy your customer. What is key here is the user experience you can deliver, not just technical sophistication.
2. Complex data structures - What data structure requirements are most likely to change? If possible, pick an architecture that makes the most likely changes relatively cheap to make. This may imply a tradeoff of some kind with other functionality.
3. Complex business logic - What are the key concepts and processes, and how are these likely to change? How easy is it to create exceptions to the rule and how can rules be verified and tested?
4. Complex integration - What are the key connecting technologies, and how well are they supported by the framework? Ideally, you can use pre-existing and tested code to integrate key areas.
5. Strict performance requirements - What is the everyday workload going to be? What mechanisms will allow you to identify bottlenecks in the system? Is there a possibility to optimize functionality by scaling horizontally or by bypassing some unnecessary functionality?
6. Scaling requirements - How can you partition your workload? How well do the core mechanisms lend to custom enhancements to fulfill scalability requirements?
7. Strict schedule requirements - What is the minimum feature set? How well does the framework support rapid implementation and testing of the minimum feature set? What are the main dependencies, and are there pre-existing modules or plugins for them?

The larger and more complex the application, the less likely you are to obtain significant productivity gains from using a framework. This is simply because having a framework can at best save you a few hundred hours of work (which should be more than what it would take for you to replicate the functionality you use). If the project is big, the time saved doing this becomes less significant compared to the time needed to build the rest of the application (e.g. the useful parts).

Comments

yash: very interesting, I think it's a common mistake under tight schedule to just pick up the most popular framework and run with it, without anlyzing the performance in case the website scales and becomes more complex!

Bob Corrick: Insightful. Thank you.

Tomasz Rakowski: A pretty good analysis, and good conclusion.

The more complex the project it the more a framework becomes a hindrance. I do find however that glue frameworks tend to play out nicer on large projects, because it's easier to replace their parts with home brewed solutions.

Full-stack frameworks tend to be highly inflexible, but are great for simple cookie-cutter websites.