Number of CF files? That depends on the methodology used - a Fusebox app is going to have more files than a page-based one.
Size of CF code on disk? Again, not really a reliable measure - more code might just mean less efficient programming ;)
Anyway, we ended up doing a couple of quick reg-ex extended searches through our codebases on two of our flagship systems - the NIMHE / CSIP Knowledge Community, and the Big Project, which I would link to, but I'm not even allowed to NAME it yet, never mind tell you where it is - to get some counts.
The KC has been incrementally developed for about three years, and the Big Project was started in February this year. Both have a Fusebox front-end with a CFC-based object model at the back-end, and I found it interesting to compare the two :
| Project | DSP files | Custom Tags | Fuseactions | CFCs | DB Tables |
|---|---|---|---|---|---|
| KC | 324 | 4 | 679 | 98 | 129 |
| Big Project | 105 | 26 | 174 | 200 | 50 |
Now, in our own heads, the two systems "feel" more-or-less the same level of complexity, but a couple of things leap out of those figures straight away -
* The KC has a colossal 679 fuseactions, which it services with 98 CFCs.
* The Big Project only has 174 fuseactions, but twice as many CFCs (200) and 26 custom tags
This is a reflection not only of an evolving methodology - on the Big Project we've moved our object model from an item/itemmanager model to a bean/controller/DAO/gateway model - but also of evolving technology.
Thanks to a liberal spattering of Creamy AJAX Goodness™, we've been able to handle things like tagging of items almost entirely within a custom tag, plus a couple of very simple fuseactions to handle the AJAX requests. You can add and delete tags without having to refresh the whole page, and as a consequence, the app feels much more responsive. This is one of the areas where AJAX can really help - provided, of course, that you're not going mad and doing whizz-bang stuff just for the sake of it.
Also, we took the decision this time round that we were going to encapsulate as much of the business logic as possible - permissions checking, etc - within the controller methods, and the bean-with-private-data model enabled us to do a lot of the core validation within the bean itself. This has the double bonus of ensuring that there's no way that invalid data can get into the database** and it removes a lot of the tedious checking code from the front-end fbx_switch files.
I'll blog more about the approach we used and the framework we worked out in a separate post - it took a bit of time and discipline to make the switch over, but we're very very glad we did.
**well, OK, no easy way... you can never make anything completely un-hackable, all you can hope to do is make it not-worth-the-effort :)
3 comments:
you missed something in the calculation: numbers of database tables. You;ll find bigger systems have more db tables.
In fact I use a simpler method:
database tables * distinct presentation views (pages).
even if something has only a few tables - if it has heaps of different presentations of that data it's a big system.
how that get coded up really depends on the system. so that's why I don't take into account fuse actions or CFC's (or weight them less).
I sometimes add a weighting for performance/scalability because a "small" system that has a million page hits a day has a few more "tricks" than a system with 20 hits a day...
just 2c worth.
Thanks Barry - I like the idea of db tables * presentation views, but again that can turn out hard to measure in a complex FB app where you try to modularise everything into re-usable templates... that's how we ended up at the Fuseaction count.
I look forward to your comments about your final architecture, noting that you stayed with Fusebox for now and didn't switch to Model-Glue or Mach-II for the controller.
Also wondering where I can find more info on the "bean/controller/DAO/gateway" approach and if you feel like it would be overkill for smaller projects (ie, 75 tables or less).
Post a Comment