Currently, I have the queries wrapped up in a single CFC. It's not the prettiest, but it works and it gets me another step closer to better OOP practices. If I were to use stored procs, I may have several stored procs that can be called individually, when needed (and they will be), and also have a "parent/service" stored proc that calls each of them when it's time to build the details page with all the information. That parent stored proc would be the one that returns the multiple recordsets. Cacheing isn't an issue at this time, nor do I think it will be any time soon. The amount of data is very small, but it does come from various sources. The pages are very fast to render. I guess what I'm struggling with is the primary intent of the objects. Let's say I have a simple, but common, three-state CF application. There is a list page, a form and a details page. Each of these pages will have some common queries, but also some individual queries. On the details page, for example, should there be a "create-this-page" service object that knows what it needs to build the final content of the details page? Or, should I expect to have several service objects? Maybe by moving my queries to store procs, I am only moving my confusion to a different tier. ;^) Thanks for the suggestions.
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Livie Sent: Tuesday, November 18, 2008 12:51 AM To: [email protected] Subject: [CFCDEV] Re: Stored Procedures, Multiple Recordsets and Components I think it would make the individual queries harder to use if you only needed one for some reason. You could add lots of boolean 'useThispart' and 'useThatPart' but it feels messy. If memory on the server is in abundance you may want to cache the worst performing queries in memory OR you could also cache the full page (or parts of the page) to the file system and regenerate the file if any of the data changes on insert, update or delete. If performance of the page is an issue I would look at caching BEFORE rolling all my queries into a big stored procedure ball. If its a one-off situation you can maybe live with the stored proc but as a general rule would be a bad idea. Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
