A "halfway solution" is probably the better idea in a case like this, but I wouldn't really call that a really procedural approach. As long as you have a CFC (or a few), with a decent API, you've got encapsulation, which means you can rework the guts as you need to without affecting much. Which is, after all, the whole point!
On Mon, May 11, 2009 at 4:36 PM, Barney Boisvert <[email protected]>wrote: > > Bah. :) > > Procedural is faster. Hell, I can write a one-template blog app > faster than I could download and configure Transfer and ColdSpring. > It'd be a nightmare to expand down the road, but that's not the point. > > In real life, I'd probably build my blog engine as a single CFC and do > everything inline (or maybe just front BlogCFC). Then if needed, I > could come back and reimplement individual methods (or the whole > thing) with whatever was better suited to the new requirements > (Transfer, Hibernate, Neat Technology Y). That sort of "half way" > provides the most important layer of abstraction for a very minimal > cost. > > As long as you've got the protection of abstraction, implementation > doesn't matter, so pick the quickest one based on the information you > have now (including anticipated future changes). But err on the side > of simplicity until you know it's worth the extra effort. > > /me throws $0.02 > > cheers, > barneyb > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
