Does my fat-client application belong in the MVC pattern?

Question

The web-based application I’m currently working on is growing arms and legs! It’s basically an administration system which helps users to keep track of bookings, user accounts, invoicing etc. It can also be accessed via a couple of different websites using a fairly crude API.

The fat-client design loosely follows the MVC pattern (or perhaps MVP) with a php/MySQL backend, Front Controller, several dissimilar Page Controllers, a liberal smattering of object-oriented and procedural Models, a confusing bunch of Views and templates, some JavaScripts, CSS files and Flash objects.

The programmer in me is a big fan of the principle of “Separation of Concerns” and on that note, I’m currently trying to figure out the best way to separate and combine the various concerns as the project grows and more people contribute to it.

The problem we’re facing is that although JavaScript (or Flash with ActionScript) is normally written with the template, hence part of the View and decoupled from the Controller and Model, we find that it actually encompasses the entire MVC pattern... Swap an image with an onmouseover event - that’s Behaviour. Render a datagrid - we’re manipulating the View. Send the result of reordering a list via AJAX - now we’re in Control. Check a form field to see if an email address is in a valid format - we’re consulting the Model.

Is it wise to let the database people write up the validation Model with jQuery? Can the php programmers write the necessary Control structures in JavaScript? Can the web designers really write a functional AJAX form for their View? Should there be a JavaScript overlord for every project?

If the MVC pattern could be applied to the people instead of the code, we would end up with this:

• Model - the database boffins - “SELECT * FROM mind WHERE interested IS NULL”
• Control - pesky programmers - “class Something extends NothingAbstractClass{…}”
• View - traditionally the domain of the graphic/web designer - “”

…and a new layer:

• Behaviour - interaction and feedback designer - “CSS3 is the new black…”

So, we’re refactoring and I’d like to stick to best practice design, but I’m not sure how to proceed. I don’t want to reinvent the wheel, so would anyone have any hints or tips as to what pattern I should be looking at or any code samples from someone who’s already done the dirty work? As the programmer guy, how can I rewrite the app for backend and front end whilst keeping the two separate?

And before you ask, yes I’ve looked at Zend, CodeIgnitor, Symfony, etc., and no, they don’t seem to cross the boundary between server logic and client logic!

Answer 1

You and everyone else with a brain is asking this question and it's a sticky one. A really good Information Architect thinks in terms of usability, behaviors and flow, although he/she may not even know how to use design tools or be able to draw or program. If they can get an interface into a sketch, the designers can make it pretty. Let the designers do the looky feely STATIC stuff--that's what they are good at. Provide IA with a library of front-end behaviors that they can specify for screen objects. They don't implement this stuff, they only USE it. This is much easier if you use a front end tool such as JQuery, and it's great if you have a front end guru who understands both design & the back end quite well. Separate your javascripts into their own directory and always link them as external files. All the PHP frameworks have methods to do this dynamically. I have toyed with the idea of a config structure that maps files to all the front end stuff that they load so each individual view only loads what it needs. But you are absolutely right: There is a whole nother sub-MVC for the clientside that lives primarily within the views of the overall MVC. I think you can partition off the Ajax stuff (when the view needs to refer back to the server) I document Ajax controller methods as ajax methods and don't call them otherwise. A lot of it is having everyone on your team buy into the division of labor paradigm. It will just cause them to write more decoupled reusable code whatever framework you ultimately choose to hang it on. And you're right, you can do the front end encapslation with all of them, but NONE of them enforce good front end encapsulation, I think that's still in the realm of DYI. Good luck.