Thanks Bill So far, I've usually always used the single query as there's no point sticking to OO best practice if it kills the site. Iterating over data twice just for the sake of it seems a bit much as well. I'm not sure if there will ever be an OO solution to this while we still use an RDBMS
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Bill Rawlinson > Sent: 27 October 2005 19:41 > To: [email protected] > Subject: Re: [CFCDev] Race Conditions when scoped in the > Applicationvariable > > Let me preface by saying this isn't what I do.. but .. > > Gareth, you could still do a single query,then iterate over the entire > query building a collection of user objects then pass that collection > of user objects back to the controller which would then pass it on to > be iterated over again for display purposes. > > ugh. nothing like iterating over data twice :O) It saves on DB > performance but then you lose the native benefit of CF and its cfquery > object's iterative powers; especially in regards to grouping. cfquery > is an object, using it is sticking with valid OOP. Your collections > of users are just different than single user objects. > > Personally, in CF, I don't see why that's a big deal. I'll take the > overall performance gain along with the increased maintenance over the > double iteration at this point. > > In the future, who knows, but for now using CFQUERY for sets of data > is the only way to go in my opinion. > > > disclaimer this is all when dealing with persistant data read from a > relational database. obviously there are times when I have to define > sets of data that are not within the scope of CFQUERY > > > Bill > > On 10/27/05, Gareth Cole <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm fairly new to CFCs and OO in general. I've managed to get my head > around > > a lot of the concepts and the reasoning behind them, but the gateway > object > > has me confused. > > > > The best practice would seem to be to return a collection of bean type > > objects. The trouble is, that as an application scales, the collection > of > > objects could run into the thousands. > > > > In a large application, getAllUsers() could return thousands or users, > each > > has to have it's own Read method called which adds up to thousands of > > database connections and a big performance hit. > > > > Database best practice is always to return a single query if possible. > > > > Gareth > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > > > Of Cliff Meyers > > > Sent: 27 October 2005 18:58 > > > To: [email protected] > > > Subject: Re: [CFCDev] Race Conditions when scoped in the > > > Applicationvariable > > > > > > I don't know about that. If I already have a User object to model a > > > single user why should the representation of a large number of users > > > be anything but a collection of User objects? I'd much rather have a > > > consistent "interface" to a user's data than having one approach for > > > single entities (getter methods) and another for batch data (direct > > > access of database column names). For an object property firstName > > > I'll have a getter called getFirstName(). However the column name > > > might be called FIRST_NAME or FIRST_NAME_TXT because of an overzealous > > > DBA. So the naming conventions will be inconsistent unless I go > > > through the trouble of doing "SELECT FIRST_NAME_TXT as firstName" in > > > my SQL. The only problem is that the mapping of column name to > > > property name is already defined in my DAO. It seems like you have no > > > choice but to maintain the same data in two places. Besides, what > > > happens if I change the storage medium to XML? Now my Gateway will > > > return a different data structure that the consumer of the Gateway > > > needs to learn about. I'd much rather let my Gateway just return an > > > array of Beans instead. There's also other problems down the road > > > when an Employee's salary goes from being just a "salary" value to > > > sometihng like "salary + bonus". I'm going to update the Bean and/or > > > DAO to be aware of that, but usin the "Gateway returns query object" > > > pattern my only real choice is to write SQL to return salary as > > > "salary + bonus" or modify the recordSet after it comes back from the > > > DB. > > > > > > Anyways, sorry for droning on. I know how these debates can get. > > > I've been spending time with Hibernate lately and love the way it > > > returns an array of objects when I do a query against the DB. It just > > > seems like the most self-consistent way to deal with more than one > > > entity. > > > > > > > > > On 10/27/05, David Ross <[EMAIL PROTECTED]> wrote: > > > > Well, I think CF's query is a great abstraction and should be used > when > > > > appropriate. When you have a "listing" page, it's going to be easier > to > > > > work with a query than a list of objects. While languages that have > more > > > > OO features tend to lean towards lists of objects, I don't think > using > > > > queries makes your model not OO... think of a query of users as a > > > > "UserListing" object. It contains aggregate data about a set of > objects, > > > > and it has many features that would difficult to implement if you > used > > > > something else (think QofQ). Again, it's an "abstraction" of a bunch > of > > > > objects, and I don't think that makes your model any less OO. > > > > > > > > -Dave > > > > > > > > >>> [EMAIL PROTECTED] 10/27/05 11:42 AM >>> > > > > Writing a Gateway CFC that returns data in the form of a query > object > > > > sort of mucks up encapsulation though, doesn't it? That was one of > > > > the things that always bugged me about trying to implement a "pure" > OO > > > > model using CFCs. > > > > > > > > > > > > On 10/27/05, David Ross <[EMAIL PROTECTED]> wrote: > > > > > Yes! (although I would typically throw in a "UserGateway" to > perform > > > > the > > > > > aggregate heavy lifting - meaning UserService.getAllUsers() would > call > > > > a > > > > > method on the UserGateway to retrieve that data). > > > > > > > > > > -Dave > > > > > > > > > > >>> [EMAIL PROTECTED] 10/27/05 11:21 AM >>> > > > > > I am one who has often been guilty of having my object cfcs > perform > > > > > CRUD. I > > > > > am trying to learn to get away from that habit. Is it accurate to > say > > > > > that > > > > > for an object like "user", one would create a user.cfc > userService.cfc > > > > > and > > > > > userDao.cfc to acheive what you are suggesting David? > > > > > > > > > > On 10/27/05, David Ross <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > It's very relevant to the "outside" world. Not to degrade his > > > > question > > > > > > into a discussion of semantics, but if you handed me a "user > > > > object", > > > > > I > > > > > > would expect it to model a user. I would not expect it to be > able to > > > > > > create, delete, or persist *other* user objects. I wouldn't > expect > > > > it > > > > > to > > > > > > be able to persist itself either. If you don't want "outside > world" > > > > > code > > > > > > that creates or persists users to know about DAOs, then that's > all > > > > the > > > > > > more reason to write a service layer. Your "UserService" would > have > > > > > > methods like createUser():User, saveUser(User):void and > > > > > > fetchUserById(id):User, as well as methods like > getAllUsers():query. > > > > > > Your "outside" world would need to know how to interact with the > > > > > > UserService, and how to interact with the User objects that it > > > > accepts > > > > > > or returns. Having a user object that both models a user AND > > > > performs > > > > > > service-style methods is an example of a monolithic object that > > > > > quickly > > > > > > becomes difficult to maintain (and is not cohesive it all). > > > > > > > > > > > > I'm sure those currently tearing apart MM's Petmarket app would > > > > agree > > > > > :) > > > > > > > > > > > > > > > > > > >>> [EMAIL PROTECTED] 10/27/05 8:27 AM >>> > > > > > > >why is variables.oUser adding and deleting users > > > > > > > > > > > > well, right or wrong, I dont see why anything that interfaces > with > > > > the > > > > > > object even needs to know about the concept of a DAO. > > > > > > > > > > > > So, all the code that is referencing oUser needs to know is to > ask > > > > the > > > > > > factory for an object, and then call the functions on the > object. > > > > > > > > > > > > The fact that the user object passes the call on to the > persistence > > > > > > layer, > > > > > > be that database, file system, whatever, is irrelevant to the > > > > outside > > > > > > world. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] [mailto:cfcdev- > [EMAIL PROTECTED] > > > > > > Behalf Of David Ross > > > > > > Sent: 27 October 2005 13:03 > > > > > > To: [email protected] > > > > > > Subject: RE: [CFCDev] Race Conditions when scoped in the > > > > > > Applicationvariable > > > > > > > > > > > > > > > > > > Along those lines, why is variables.oUser adding and deleting > users? > > > > > > > > > > > > -Dave > > > > > > > > > > > > >>> [EMAIL PROTECTED] 10/27/05 3:48 AM >>> > > > > > > <cfset Application.userFactory = CreateObject('component',' > > > > > > com.framework.user') /> > > > > > > > > > > > > > > > > > > > > > > > > <cfset Application.userFactory().AddUser(UserObject) /> > > > > > > > > > > > > <cfset Application.userFactory().DeleteUSer(UserObject) /> > > > > > > > > > > > > > > > > > > > > > > > > bit confused by this code. > > > > > > > > > > > > > > > > > > > > > > > > 1) userFactory is not a function. > > > > > > > > > > > > 2) why is the factory performing CRUD operations? the factory > should > > > > > > return > > > > > > an instance of the user component? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <cfset Application.userFactory = CreateObject('component',' > > > > > > com.framework.userfactory') /> > > > > > > > > > > > > > > > > > > > > > > > > <cfset variables.oUser = application.userFactory.newUser()><!--- > > > > > return > > > > > > a > > > > > > new instance of the user object ---> > > > > > > > > > > > > > > > > > > > > > > > > <cfset variables.oUser.AddUser(argumentCollection=form) /> > > > > > > > > > > > > <cfset variables.oUser.DeleteUser(User_ID=form.user_id) /> > > > > > > > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] [mailto:cfcdev- > [EMAIL PROTECTED] > > > > > > Behalf > > > > > > Of Andrew Scott > > > > > > Sent: 27 October 2005 06:49 > > > > > > To: [email protected] > > > > > > Subject: [CFCDev] Race Conditions when scoped in the Application > > > > > > variable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok I am looking at a solution where I am keeping track of > certain > > > > > > details > > > > > > that users do on the website. I was looking at creating it in > the > > > > > > application scope. But I am unclear on a few things. > > > > > > > > > > > > > > > > > > > > > > > > If I set up the scop in this manner. > > > > > > > > > > > > > > > > > > > > > > > > <cfset Application.userFactory = CreateObject('component',' > > > > > > com.framework.user') /> > > > > > > > > > > > > > > > > > > > > > > > > Now through the code I will make reference to it like such. > > > > > > > > > > > > > > > > > > > > > > > > <cfset Application.userFactory().AddUser(UserObject) /> > > > > > > > > > > > > <cfset Application.userFactory().DeleteUSer(UserObject) /> > > > > > > > > > > > > > > > > > > > > > > > > Now what I am not clear on is the internals of this, for > example. > > > > The > > > > > > user > > > > > > object has a structured array that contains the information for > all > > > > > > users > > > > > > logged into the system, and other tid bits of information. My > > > > question > > > > > > is, > > > > > > should I be locking access to variables when setting inside or > not? > > > > > > > > > > > > > > > > > > > > > > > > This is where I am a little unclear, I have had a look at the > > > > Mach-II > > > > > > framework and it doesn't seem to do this. Except when setting > the > > > > > > application.userfactory in the application scope to begin with. > > > > > > > > > > > > > > > > > > > > > > > > Could someone give me a little more run down on this, as well as > > > > > > hopefully > > > > > > clear the process up a little more for me as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > Andrew Scott > > > > > > Analyst Programmer > > > > > > > > > > > > CMS Transport Systems > > > > > > Level 2/33 Bank Street > > > > > > South Melbourne, Victoria, 3205 > > > > > > > > > > > > Phone: 03 9699 7988 - Fax: 03 9699 7976 > > > > > > > > > > > > > > > > > > Quote: > > > > > > A pessimist thinks everybody is as nasty as himself, and hates > them > > > > > > for > > > > > > it. - George Bernard Shaw > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > ---- > > > -- > > > > > > ---------------------------- > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > > > [email protected] with the words 'unsubscribe cfcdev' as the > > > > subject > > > > > of > > > > > > the > > > > > > email. > > > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org > <http://www.cfczone.org>) > > > > > and > > > > > > supported by CFXHosting > > > > > > (www.cfxhosting.com <http://www.cfxhosting.com>). > > > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > > > An archive of the CFCDev list is available at > > > > > > > > > > > > > > > www.mail-archive.com/[email protected]<http://www.mail- > > > archive.com/[email protected]> > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > > > [email protected] with the words 'unsubscribe cfcdev' as the > > > > subject > > > > > of > > > > > > the email. > > > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org > <http://www.cfczone.org>) > > > > > and > > > > > > supported by CFXHosting > > > > > > (www.cfxhosting.com <http://www.cfxhosting.com>). > > > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > > > An archive of the CFCDev list is available at > > > > > > > > > > > > > > > www.mail-archive.com/[email protected]<http://www.mail- > > > archive.com/[email protected]> > > > > > > > > > > > > > > > > > > ----------------------------------------- > > > > > > CONFIDENTIALITY NOTICE: This email and any attachments may > contain > > > > > > confidential information that is protected by law and is for the > > > > sole > > > > > > use of the individuals or entities to which it is addressed. If > you > > > > > are > > > > > > not the intended recipient, please notify the sender by replying > to > > > > > > this email and destroying all copies of the communication and > > > > > > attachments. Further use, disclosure, copying, distribution of, > or > > > > > > reliance upon the contents of this email and attachments is > strictly > > > > > > prohibited. To contact Albany Medical Center, or for a copy of > our > > > > > > privacy practices, please visit us on the Internet at > > > > > www.amc.edu<http://www.amc.edu> > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > > > [email protected] with the words 'unsubscribe cfcdev' as the > > > > subject > > > > > of > > > > > > the > > > > > > email. > > > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org > <http://www.cfczone.org>) > > > > > and > > > > > > supported by CFXHosting > > > > > > (www.cfxhosting.com <http://www.cfxhosting.com>). > > > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > > > An archive of the CFCDev list is available at > > > > > > > > > > > > > > > www.mail-archive.com/[email protected]<http://www.mail- > > > archive.com/[email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > > > [email protected] with the words 'unsubscribe cfcdev' as the > > > > subject > > > > > of > > > > > > the email. > > > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org > <http://www.cfczone.org>) > > > > > and > > > > > > supported by CFXHosting > > > > > > (www.cfxhosting.com <http://www.cfxhosting.com>). > > > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > > > An archive of the CFCDev list is available at > > > > > > > > > > > > > > > www.mail-archive.com/[email protected]<http://www.mail- > > > archive.com/[email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > > > [email protected] with the words 'unsubscribe cfcdev' as the > > > > subject > > > > > of > > > > > > the email. > > > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org > <http://www.cfczone.org>) > > > > > and > > > > > > supported by CFXHosting (www.cfxhosting.com > > > > > <http://www.cfxhosting.com>). > > > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > > > An archive of the CFCDev list is available at > > > > > > > > > > > > > > > www.mail-archive.com/[email protected]<http://www.mail- > > > archive.com/[email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > ~Dave Shuck > > > > > [EMAIL PROTECTED] > > > > > www.worldwildweb.biz <http://www.worldwildweb.biz> > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > > [email protected] with the words 'unsubscribe cfcdev' as the > subject > > > > of > > > > > the email. > > > > > > > > > > > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting > > > > > (www.cfxhosting.com). > > > > > > > > > > > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > > > > > > > > > > > An archive of the CFCDev list is available at > > > > > www.mail-archive.com/[email protected] > > > > > > > > > > > > > > > > > > > > ----------------------------------------- > > > > > CONFIDENTIALITY NOTICE: This email and any attachments may contain > > > > > confidential information that is protected by law and is for the > sole > > > > > use of the individuals or entities to which it is addressed. If > you > > > > are > > > > > not the intended recipient, please notify the sender by replying > to > > > > > this email and destroying all copies of the communication and > > > > > attachments. Further use, disclosure, copying, distribution of, or > > > > > reliance upon the contents of this email and attachments is > strictly > > > > > prohibited. To contact Albany Medical Center, or for a copy of our > > > > > privacy practices, please visit us on the Internet at www.amc.edu. > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > [email protected] with the words 'unsubscribe cfcdev' as the > subject of > > > > the email. > > > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting > > > > (www.cfxhosting.com). > > > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > > > An archive of the CFCDev list is available at > > > > www.mail-archive.com/[email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > > [email protected] with the words 'unsubscribe cfcdev' as the > subject of > > > > the email. > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting > > > > (www.cfxhosting.com). > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > An archive of the CFCDev list is available at > > > > www.mail-archive.com/[email protected] > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > [email protected] with the words 'unsubscribe cfcdev' as the subject > of > > > the email. > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting > > > (www.cfxhosting.com). > > > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > > > An archive of the CFCDev list is available at www.mail- > > > archive.com/[email protected] > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > [email protected] with the words 'unsubscribe cfcdev' as the subject > of > > > the email. > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > > > (www.cfxhosting.com). > > > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > > > An archive of the CFCDev list is available at www.mail- > > > archive.com/[email protected] > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of > the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > > > CFCDev is supported by New Atlanta, makers of BlueDragon > > http://www.newatlanta.com/products/bluedragon/index.cfm > > > > An archive of the CFCDev list is available at www.mail- > archive.com/[email protected] > > > > > > > > > -- > [EMAIL PROTECTED] > http://blog.rawlinson.us > > If you want Gmail - just ask. > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of > the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at www.mail- > archive.com/[email protected] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
