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|
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 :)