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:310178 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
