A Question of Controllers

So I'm nearing the end of the planning stage of a pretty big project. By big, I mean it's for a big blue chip company that you will certainly have heard of, and the project itself is big in terms of code. I can't go into too much detail about the specifics, but if you think of Flickr, del.icio.us, Smartgroups, Craigslist, plus the NIMHE KC all rolled into one, you're not far off. And the timescale, as ever, is extremely tight.

We've almost got enough of the functionality nailed down to start working out the entity relationship diagram (ERD) and object model that we'll be using, and decide on what framework to use.

I'm pretty sold on the idea of using a ValueObject/TransferObject + DAO + Controller pattern for the entity objects, and keeping all data members private - I've used this on a previous project with diabolical levels of complexity in the data, and it was one of the best design decisions I ever took. The extra tedium of having to write getters and setters over and over again, paid off ten fold in having the complexity encapsulated. Plus it meant we could do neat value-adds like having the object itself keep track of when it had been modified, and enable/disable "save" buttons appropriately, to make the app feel more like a desktop app - which is, after all, The Holy Grail of t'interweb.

So that's the Model part of MVC pretty much sorted, and the persistence layer should be encapsulated nicely within the Model itself. The View part is pretty transferable whatever framework we end up using - a display template is a display template and should never be anything other than a display template, whether in Fusebox, Mach-II or Model-Glue, or whatever.

The decision I am still pondering is which framework to use for the Controller part of the app. We've tended to use a home-brewed hybrid style up till now - a Fusebox 3 app with CFCs instead of act_ files, which we tentatively called HOOF - Hybrid Object-Oriented Fusebox. However, in some recent projects of comparable scale, there's been several times I've found myself thinking "damn, I'm copying-and-pasting this bit of code AGAIN, if I could just broadcast an event this could be so much easier..."

I'd like to make the leap to Mach-II, or Model-Glue, but the trouble is that tight timescale, and the rest of the team. Everyone here is very comfortable with our HOOF methodology, and from my previous tinkering with small Mach-II apps, making the leap to truly event-driven architecture is a subtle but significant shift in thinking. You can find yourself feeling lost without the safety of a procedural code section explicitly tying the disparate bits together, like the first time you try lead-climbing a large wall without the reassuring sight of the rope stretching out above you.

So when the deadline is tight, the pressure is high, and the app is fiendishly complicated, is it worth taking the risk of moving to a methodology which promises to help manage the complexity, but in which the team has little or no experience? Or should we stick with an approach which has its limitations, but we can code in our sleep?

Known knowns vs. Unknown Unknowns - Decisions, decisions.....