I also presented on this very topic at the Frameworks conference earlier this year. My slides and code are available for download:
http://www.briankotek.com/blog/files/framework_agnostic_models_presentation_code.zip The takeaway should be that when your model is well architected and encapsulated, switching from say Fusebox to Mach-II should only require rewriting the config XML files and slight modifications to the views to support the way Mach-II passes event arguments. You should also be able to hit your model directly from a Flex front end with no (or extremely few) changes required. The question of ColdSpring and ORM is really separate from the UI-Controller frameworks. ColdSpring, Reactor, and Transfer play well with any of them. I'd say technically Model-Glue 2 has a slight edge because it already has ColdSpring embedded within it (the framework itself uses ColdSpring to configure itself) and also has built in ORM support (via the built in ORMAdapter and scaffolding). But getting ColdSpring to work with the other frameworks is not difficult at all, nor is using one of the ORM frameworks. Basically, I'd be more concerned about which UI-Controller framework the team was most comfortable with, as well as the challenge of really understanding best practices regarding ColdSpring and the ORM frameworks themselves. These are the hard parts. Hope that helps. On 7/23/07, Cutter (CFRelated) <[EMAIL PROTECTED]> wrote: > > Jason, > > There is a fantastic sample app, called LitePost, that Matt Woodward, > Peter Farrell, Chris Scott, and few others contributed to, that is > available on GoogleCode. It's way undocumented, but basically it shows a > simple blogging application. The 'Model' layer is a single set of CFCs, > with a single ColdSpring config file. The 'Controller' and 'View' layers > are done in MG, Mach-II, and Fusebox, allowing you to try it on each > one. Really great way of showing that, if written properly, an > application can fairly easily port between any framework. > > Each framework app uses the same set of 'Model' components, as well as > the same ColdSpring config file. > > Steve "Cutter" Blades > Adobe Certified Professional > Advanced Macromedia ColdFusion MX 7 Developer > _____________________________ > http://blog.cutterscrossing.com > > Jason Fill wrote: > > Thank you all for the input on this topic. I defiantly think that in > the short term and to get started Fusebox would have the smallest learning > curve - which would allow us to get going fairly quick. While that is > great, our main goal here is to adopt a framework that will be flexible and > grow with us. We do not want to go down a path and in 2 years say....man I > wish we would have taken a little extra time to adopt xyz framework over the > one we chose. > > > > I think we have pretty much decided that we are going to use ColdSpring > to take care of IoC. So let me throw this out, does any one of the > frameworks lend itself better to the use of ColdSpring, and possible > Transfer or Reactor? I have used ColdSpring with a Fusebox app and it > seemed to work well, however I am not sure if it just works easier or better > with other frameworks. Sorry if these seem like redundant questions, just > trying to get everything that is on the top of my head out. > > > > On a side note, I am the only one that has any Fusebox experience and > would not like to put that into our equation in this evaluation of which is > best suited for us. > > > > Thanks again! > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Enterprise web applications, build robust, secure scalable apps today - Try it now ColdFusion Today ColdFusion 8 beta - Build next generation apps Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:284403 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
