@Alan, I agree. That's why I use objects religiously, use an IBO for collections so performance isn't a big concern and would use caching if I found myself having a performance problem. I really like the consistency of using objects for everything and have never had a problem with the approach over 40 projects. It also makes refactoring way easier as I don't have to try and guess which of my business objects are going to have complex business logic upfront. I just have a standard approach to all business objects that is capable of handling complex business rules elegantly should they turn up - and I find that they often do.
Best Wishes, Peter On 3/31/08 2:04 PM, "Alan Livie" <[EMAIL PROTECTED]> wrote: > > @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 -~----------~----~----~----~------~----~------~--~---
