Wednesday, January 18, 2006

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.....

5 comments:

Alistair Davidson said...

Just come out of another meeting about this project - looks like we're also building GMail aswell....

Anonymous said...

haha, gmail too. You are going to have your hands full. You're in a difficult situation, and the fact is, getting yourself and everyone in your team into a new framework is going to take some time.

Given your existing fusebox-like structure, you can probably move to FB41 without too much trouble, but learning the XML language will be challenging.

MG or MII will work even better with your OO Model, but figuring them out can be tough.

Still, though, I do recommend a public framework, for standardization and support, if nothing else. Sucks that nobody can really make that decision for you, huh?

Anonymous said...

I've been looking at migrating away from HOOF too. Sean Corfield's frameworks sample app was very interesting - in my tests, FB41 was much quicker than all the others. Some frameworks looked to REALLY slow response time down. Am currrently refactoring a small HOOF app to get all that illegal code out of the "controller" and then will redo in FB41 to see how things slow down/speed up. Will let you know.

Alistair Davidson said...

Hi Matt

From my experiments with Mach-II, I found that you absolutely had to turn Debugging Info off and set the MACHII_CONFIG_MODE to 0 or -1 so that
Mach II does not reload the XML configuration file on each request, in order to get any reflection of real-world performance. I'd be interested to see what your FB4 results were.

Anonymous said...

I think the performance issue is the wrong thing to focus on when you compare FB/Mach-II/Model Glue. It is true that FB4.1 is the fastest but I have used Mach-II for large scale projects and it performs very well. As Alistair says, the VERY SLOW RESPONSE TIMES mentioned by a lot of people are due to the way ColdFusion handles debug output for CFC-heavy apps (nothing unique to Mach-II).