Why I’m an MVC bitch
With the popularity of MVC frameworks such as (or because of) RoR (Ruby on Rails) I decided to see what all the fuss was about. Well let me tell you, as is the case of life after the introduction of a Tivo - I cannot foresee going back!
I remember, back in the day, learning and using the various system development lifecycles, processes, and models. I remember even advocating completing a design before writing the first line of code. Ahh - those were he days…
In web development, release cycles seem to have been reduced to hours and being able to respond rapidly to changing needs and user feedback is now a critical element in the success of a project.
So how can we enable this level of agility on applications from the get go? In the past the mantra has been “reusable objects”. Surely leveraging the fact that 80% of all applications share the same functionality (statistic obtained using the well established development estimation practice of pulling a figure out of the air) tells us that abstracting and refining and reusing this common functionality will a) provide us with reliable code, and b) enable us to skip this development effort and thus allow us to produce more stable applications faster.
This is all true and reasonably valid except for a couple of points:
1) With the pace of changing technologies being as fast as it is, old (legacy) components are often no longer relevant and as such their “reuse value” is negligible
2) In projects following formal development lifecycles, the actual coding was generally less than 50% of the effort and as such the development savings have little impact to the overall project
3) The primary reason for project failure is a mismatch between the deliverables and expectations (be that functionality, usability, time, or cost)
Understanding this, a more effective way to improve the success rate of a project is to engage application users early and frequently. In addition to this you need to be able to respond to the changes/refinements requested.
This is where an MVC framework really shines.
Here is where I interject the caveat that my current framework of choice (and hence where my experience lies) is CakePHP and as such the features and experiences may not be available in all frameworks.
In the first 5 minutes you can install the framework and have the default page being delivered. From then on there is no required order of development - I can add functionality or design iteratively.
For functionality, once I create a database table I can produce a model with its relationships and validation rules in minutes and I automatically get the CRUD functionality provided for me. I can then decide on an action I want the application to perform and write a controller function to perform this functionality. If it requires interaction with the database, most of the work can be done by calling built in functions on the model(s) and as such the amount of coding required for each discrete piece of functionality is generally quite small. I will then route a URL to this function and hack up a basic HTML view to present the results. I now have a working piece of functionality on the site and can go on to the next piece. If I need to update the database and alter a table that I have already created a model for, all I need to do is update the database and give the model a quick once over in case I need to add, alter, or remove a relationship or validation rule. My controllers will now have access to the updated database structure.
At the same time if I have a designer (or at some point when I am feeling creative) attention can be put to creating HTML templates, styles and the other visual elements that comprise the views. Although there is a fair amount of coupling between the views and controllers (i.e. the controllers explicitly provide the views with data and as such the views need to know the names of the variables being offered), this binding can easily be put off until the controller is complete (or at least is passing all the variables the view expects) and added in later.
As a further enticement, good frameworks will provide a number of additional “tools” to facilitate rapid development. Scaffolding will automatically create CRUD forms to enable you to interact with your data. Helpers for HTML and form generation and validation provide a mechanism to simplify the standardising of experience so that (for example) the whole application reacts to errors in a common manner.
These are just some thoughts and experiences I have had making the (both technical and emotional) jump from n-tier object oriented development to MVC - and as a result I find myself more and more becoming a full-on MVC bitch!
Posted on Monday, July 31st, 2006 at 1:44 pm.
Filed under Design, Development.
Subscribe to RSS 2.0.
Leave a comment or trackback.