The era of the lightweight framework is in full swing and has enabled developers to quickly execute everything from our most random inklings to more advanced and complex ideas. We can have an application up and running in minutes. We’ve implemented the Model-View-Controller framework into our web site development projects, including Intervals, our web-based time tracking and task management software. Good design patterns like MVC are ideal for agile development. Because the framework dictates much of the thinking of where and how code should go, it makes it easier to quickly add features and isolate bugs. However, as we continue to tweak and evolve our application we are finding some areas where the ‘rules’ of the MVC framework must be bent or broken. It is difficult as a developer to sacrifice clean and structured code for any reason, but it is absolutely necessary when web site performance is at stake. The end-user will never see the elegant server-side code you’ve developed, but they will be effected by slow site performance. Here are a few examples of when the MVC framework may have to be compromised for performance.
In this post…
When the model disagrees with the database
Most MVC frameworks assume a one-to-one relationship between a model and a table in the database. And a list model takes this concept one step further by representing a list of objects in a table. For example, a project management application, like Intervals, will display lists of projects throughout the application. And there are places in the application where we need to filter the list of projects. In one scenario, we need to show only those projects that have time entered on them for this month. Allowing the MVC framework to dictate this SQL query will always start with the project table in the database, doing joins on the time table to whittle down the list. Overriding the query to start with the time table and then do its joins on the project table reduces the query time by a factor of 12. The performance gain was well worth getting our hands dirty in the inner workings of the framework.
Displaying large sets of data
When pushing around large sets of data, like reports, there are several layers of the framework through which the data has to pass. The data is dredged up from the database by the model, passed through the controller, and finally delivered unto the view. This is normally done using arrays, which require memory and time to build and parse. Here we are up against an obvious limitation of the MVC framework. Adhering to the design pattern is costing us, so we have to go around it. Modifying the view layer to connect directly to the database, using something like cursors, allows the database to handle the array-like structure of the report data. It’s not a pretty solution, but the performance gain can be significant.
Helper functions
There are places throughout a framework that helper functions will be required. For example, display functions will properly format timestamps and currencies into the requested locale. Formatting can be done at the database level to avoid any further modifications after the data is queried. The model level may require error message formatting when validating data. And the view obviously requires these functions for displaying dates and currencies to the user. This scenario isn’t really addressed by the MVC design pattern, though we’ve found the best way to resolve this is to create helper functions that can be accessed anywhere within the framework.
These are just a few examples of how developers may need to think outside of the MVC framework. Got any others?
