Risto Juola
Ab absurdo, ad libertatem.
Previous   |   Next       

MVC and Web Apps: Soil and Fodder

Mar 08, 2006

The Sitepoint article MVC and Web Apps: Oil and Water is an interesting read, and a good engineering reference, being as link heavy as it is. But, I daresay whether or not MVC is the best option for you, during this phase of the internet's existence, will be driven by the scope, intent and resources of your project, not solely whether or not it's being deployed on the web (you are thoroughly examining your technological options, discussing these ad nauseam with your peers, and tempering this with existing and future business requirements prior to implementation, aren't you? Of course, nowadays the research and design analysis phase of a project raises the issue of choice -- there are a myriad of languages, frameworks, design models, and composite design models to choose from. You'll have to cut and run at some point, or nothing will ever materialize). I don't know that the article was meant as a blanket statement regarding all categories of applications deployed on the web, and the article's discussion certainly appears to be geared towards large scale applications, but its title doesn't leave much room for interpretation.

I'm not saying you should always use MVC and/or Ruby on Rails; you should use the best tool for the job, and if at all possible have a good time while doing so. MVC and Rails are just more propitious tools to add to your collection, and they are obviously pertinent to web apps.

In my case, my web applications focus on content delivery, and in this domain Rails neatly organizes and provides a large percentage of the functionality that I've spent so much time archetyping and meta-fying over the years. For example, there should be no need to spend time maintaining a semi-custom ORM layer, it should simply work. For this (that is, RoR's Active Record class) and many other reasons, I'm considerably more excited about using Rails than I was when I first began experimenting with frameworks a few years ago.

I've been designing Code Blue in my spare time over the last ten months, and as far as personal projects go the system is large. Happily, I won't have to redesign any component of my platform in order to interface it with Rails; I can readily swap out components of my design and replace them directly with functionality extant in Rails -- which further encourages me that Code Blue's design is sound, and offers some display of the experience, forethought, and power behind Rails.

Regardless of the framework you find suitable to your efforts, I recommend reading Agile Development With Rails. It's a great read for web developers at large, for;

  • it has a straight forward and easy access discussion to common security issues;
  • it crystallizes many of the lessons that (should) have been learned with respect to application design; i.e. platforms with problem domains that are well thought out, with scalable interfaces, and the ability to adapt systematically instead of organically to handle future tasks that may be thrown at them, while remaining highly focused on the task at hand;
  • it introduces powerful organizational approaches and application designs (many of the topics covered are things that conscientious programmers will already know or at least have pondered -- to MVC or not to MVC [Rails of course compelling you to go MVC], design patterns, loosely coupled design, test driven development, development tiers [development, test, live], et cetera);
  • and if you haven't used frameworks before, this is a good introduction to meta-thinking (for lack of an existing phrase -- although this sounds like a phrase someone else has probably already said).

I implemented a prototype for Code Blue using my own existing PHP framework / PEAR / PHPlib and it took 1.5 months to validate the design in my spare time. I was able to complete a similar prototype using Rails in two nights. Granted, I had already hammered out a number of architectural and low level details with my PHP prototype, but this accounted for something like 10% of the productivity gap, the other 90% being inside Rails. Bear in mind that I'm not only in the process of discovering my problem domain, but I'm also learning Ruby and Rails as I go along.