Most of the benefits from a framework (at least in my view) come from the bookkeeping that the framework takes care of automatically. For example, ColdSpring manages dependency injection, so I don't have to write any code to do that. ColdSpring also provides AOP functionality which provides a very nice way to wrap functionality around other existing functionality, and again, takes care of all the mundane accounting that is required to make that work.
Similar examples exist for other frameworks. All the Front Controller frameworks provide configuration languages for the app (which you don't have to write), automated caching of execution plans (so you don't have to write them), a framework for managing intra-request state (so you don't have to write one), etc. Frameworks also provide consistency between applications. If I've worked on a FB5 app anywhere, chances are good I'll be able to switch to a different FB5 app (quite possibly at a different company in a different industry) and already understand that app to a very high degree. That's very valuable if you have a growing or rotating staff. In short, there's nothing you NEED a framework for, but there are a lot of smart developers out there, and I generally prefer to trust code that someone else wrote (and tested, exercised, and then released to a large community) over code that I wrote (with no other vetting). Especially for the mundane (but VERY important) glue bits. And this perspective has nothing to do with CF, it's global to programming, which is why there is such a huge affection for Spring, Struts, Hibernate, Tapestry, etc., etc. beyond CF's borders. It's worth mentioning also that your current framework/methodology seems effortless to you largely because you're very familiar with it, and understand all it's ins and outs. A new framework will automatically seem a lot more cumbersome initially, because you lack that familiarity with it. cheers, barneyb On 5/2/07, Jeff Small <[EMAIL PROTECTED]> wrote: > We've (our development team) been using Dreamweaver, and we use it internally > for checking in/out documents. We write CFCs and utilize Dreamweaver's > "Components" tab. We use store all of our "most used code" in snippets that > we all share, and we're all trained Computer Science graduates (not designers > or graphic artists who "picked up" web "programming")... > > Why would we use a framework? What would be the benefit? > > I only ask because all of these framework discussions always leave me with > the feeling of, "hmmm... that sounds really 'neat' but with our workflow it > seems really redundant..." or perhaps better said, "that seems like a lot of > overhead to achieve what we already achieve pretty effortlessly"... > > Is there something I'm missing from a framework that I don't get from simply > utilizing all the tools available in Dreamweaver? Even Ajax, which gave me > pause a few months ago, thinking, "hmmm, now I *might* need a framework to > implement some of these whiz-bang Ajax doo-hickeys" now seems a thing of the > past with Spry shipping with Dreamweaver CS3. > > Am I missing something? We don't re-write code. We re-use everything. It's > all available in our snippet library, and our CFCs are constantly being > reused. Is there something more that we could be doing with a framework that > we're not able to do without it? > > I just thought it seemed like an "appropriate" question because of the > framework threads that have been popping up all over the place lately... got > me thinking and all... > -- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:276845 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
