Sounds like it's not a terrible idea. The pattern you're looking toward moving to is called the Service Pattern. It puts an interface into your Model. It's a good strategy if you are trying to reduce complexity (like number of functions in a component), split out concerns (like public versus private), accommodate a changing architecture (like you're doing), and especially if you will expose any of your application through web services later.
Be careful that you don't put all your business logic in the services you create, creating an anemic domain model problem. Also, I would say congrats to you for seeing a problem, realizing a viable solution, and only later finding out that it's an already-well-known pattern. I think that's the mark of really knowing your stuff (and also that you should read up on your design patterns). nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Thu, Aug 4, 2011 at 8:40 AM, Scott Stewart <[email protected]>wrote: > > Ok, here goes.. > > I've got a component with a bunch of database calls, each db call function > is private. The component also contains public methods that call the > private > methods. My thought is this.. > > Separate the private functions into their own component, and use the > extends > property to stitch everything back together Any instantiation would call > the public methods. > > > > > > Any thoughts? Am I going to far with code separation.. > > > > Thanks > > > > Scott > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:346525 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
