@Patrick, I agree to a certain extent with what you're saying but you said...
' Simple queries are easy to change, even if I have to make the same change to five or six different queries.' One of the problems I had a while back was implementing a business rule in a query in a cfc only to find a few weeks later it wasn't implemented everwhere as some pages had their own <cfquery> in the page querying the same data rather than using the cfc to get the results. Unless you strictly keep everything in one place there's always the chance you'll miss something. Alan ________________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of Patrick McElhaney [EMAIL PROTECTED] Sent: 31 March 2008 18:58 To: [email protected] Subject: [CFCDEV] Re: What about performance? On Mon, Mar 31, 2008 at 1:09 PM, Peter Bell <[EMAIL PROTECTED]> wrote: > > There are certainly apps which are simple enough that OO coding is > unnecessary. I often find myself throwing together simple "cfquery at the > top of the page, cfoutput at the bottom of the page" apps from time to time > and it would be crazy (IMO) to implement an OO framework to solve those > problems. > > Equally, for very large, complex web apps, I think there is a reason that > the vast majority of them are written using objects. It does aide > maintainability of larger applications. As I've learned the hard way, most sites are mix of simple web sites and complex web apps. For example, on an e-commerce site the catalog is a simple web page. It's just a front end for a database, right? But the shopping cart may be more like a web app. Certainly the back end where products are entered is a web app. Objects come in handy when you're building a web app. And if you've already committed to using objects, why not reuse those objects to get data for things like a catalog page? If there's on thing we can all agree on, it's that reusing code / not repeating yourself is good, right? Unfortunately, the forces that affect web apps and the forces that affect web pages tend to be polar opposites. app: read and write page: read only app: typically you're working with one record at a time page: data aggregated from many sources app: fewer transactions page: lots of transactions app: most data should be up to date, all the time page: most data can be a little bit outdated If you use objects for the "app" parts and plain old queries and includes for the "pages" I think both are easier to maintain. The "app" part benefits because you don't have to worry so much about the relationships between entities. The "page" part benefits because each page is its own self-contained and very simple problem. If something changes in the database, the code may be affected in several places instead of one. But in my experience, those changes are easier than I anticipate. Simple queries are easy to change, even if I have to make the same change to five or six different queries. Patrick -- Patrick McElhaney 704.560.9117 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
