Don't feel bad, you just listed every single reason to use collections of objects and all of them are valid. I'm pretty fond of Hibernate myself, but unfortunately we don't have a similar solution in CF-land (maybe someday that will change?). Until then, I'd rather manage queries then try to create one-off solutions that likely won't scale nearly as well.
-Dave >>> [EMAIL PROTECTED] 10/27/2005 1:57:40 PM >>> 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:[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:[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]
