Knowledge of how to create objects is normally handled in a Factory. So in this case, I'd have a UserFactory that knows how to create a User and associate the correct Roles. That way the knowledge is encapsulated within the Factory and nothing outside of it needs to know how the objects are assembled.
If you feel adventurous, you might have a look at the Transfer ORM framework, which will do these sorts of things for you automatically. But that may be tackling more than you wanted to deal with right now. On Mon, Aug 4, 2008 at 6:32 PM, Dean Lawrence <[EMAIL PROTECTED]> wrote: > Thanks Brian, > > I appreciate your thoughts. I guess what I meant by "where does the > composition take place" is actually more like, "where does the population of > the composition objects take place". I have the Role attribute defined in > the User object along with getters/setters. However, where should the actual > Role bean be created before passing it to the setter method of my User > object? Should this be done in the Service layer where I initiate the calls > for my User bean? Or should it be done elsewhere, like my Gateway layer. Or > should the User bean be completely self sufficient and know how to > instantiate the RoleService to populate it's Role attribute? > > This same question would conversely apply to my save method of my User > object (if I am using some type of relation table for a one-to-many relation > for roles). Where do I loop over my role array and save the relations? In > the Service or DAO layers? > > I think for every light bulb that goes off in my mind, 3 start to flicker > and burn out!! > > Thanks, > > Dean > > > > >If you're sure the User will only ever have one role, then a roleID column > >in the User table is fine. However, in practice I would be very leery of > >such a decision, particularly with something like a Role where a User can > >almost certainly have more than one Role. In that case, a link table that > >relates userID to roleID is almost certainly the better way to go. > > > >I would have the User compose a Role (or an array of Roles). > > > >I'm not sure what you mean about "where the composition should be taking > >place" though. The only place it should matter is in the User itself. The > >Service layer doesn't represent individual users (that's what the User > >object is for) so there's really no way for the User to Role relationship > to > >have an impact on the Service, unless I'm not understanding what you're > >asking. > > > >Regards, > > > >Brian > > > > > > > > > >>>If you're sure the User will only ever have one role, then a roleID > column > >in the User table is fine. However, in practice I would be very leery of > >such a decision, particularly with something like a Role where a User can > >almost certainly have more than one Role. In that case, a link table that > >relates userID to roleID is almost certainly the better way to go. > > > >I would have the User compose a Role (or an array of Roles). > > > >I'm not sure what you mean about "where the composition should be taking > >place" though. The only place it should matter is in the User itself. The > >Service layer doesn't represent individual users (that's what the User > >object is for) so there's really no way for the User to Role relationship > to > >have an impact on the Service, unless I'm not understanding what you're > >asking. > > > >Regards, > > > >Brian > > > > > > > > > >> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:310179 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
