Hi Alan,
objUser.getAddress().setCity("Dundee") is simpler, but now you¹re sharing
the internal implementation of your user (that addresses are a composed
object within it). If you might switch between having an address object and
a city property of the user, encapsulate that design decision and have
objUser.setCity(³Dundee²) take care of things. In practice I¹d stay with
what you have above as I think you¹re going to be exposing that design
decision (having a composed address within a user) elsewhere, so I¹d stay
with the method chaining to keep your objUser class simpler.
Re: the UserDAO calling the AddressDAO, something is going to have to call
the AddressDAO if you want to encapsulate the persistence of your addresses
(which seems like a good idea). I would favor having UserService call
UserDAO.save() and AddressService.save() (which would then call
AddressDAO.save()). Why? Well, a number of reasons:
1. I see the purpose of a DAO as handling the SQL for persistence rather
than handling composition logic, so to me while a UserService should know
about composed objects (*something* has to), a UserDAO should only deal with
persisting the actual user not the composed objects.
2. You may have multiple DAO implementations over time (such as for
different db¹s), so keeping them limited to just the SQL queries makes it
easier to do this.
3. I find that my AddressService and UserService often need to speak for a
variety of reasons (not just composed saves). Given that they already speak
to each other, by channeling all communications between the Address stuff
and User stuff via the service classes, I¹m limiting the number of classes
that each cfc needs to know about. Decreasing coupling is good.
On the whole my preference would be to have the Service classes handle the
composed saves, and specifically to have UserService call UserDAO.save() and
AddressSERVICE.save() (NOT AddressDAO). In that way all of my communications
are between the service components, keeping everything nice and clean and
minimizing the number of directly interacting beans. Also means if you ever
want to dump your DAOs or move methods into or out of Gateways or whatever,
you know ALL of those design decisions are encapsulated behind your
#Object#Service (e.g. UserService or AddressService). I¹m finding that is
working out pretty well for me . . .
Best Wishes,
Peter
On 11/7/07 6:15 PM, "Sam Larbi" <[EMAIL PROTECTED]> wrote:
>
> Hi Alan,
>
> I've responded in-line below.
>
>
> On Nov 7, 2007 3:58 PM, Alan Livie <[EMAIL PROTECTED]> wrote:
>>
>> I have a bean called User that is composed of an Address bean. At the
>> moment its a 1:1 relationship.
>>
>> A factory handles the composition so when I request User I get it
>> configured with the Address bean already composed.
>>
>> My question is in 2 parts:
>>
>> 1) When I want to get and set properties of the Address bean from
>> client code should I
>> a) use objUser.getAddress().setCity("Dundee") or
>> b) should I have setters in the User object that delegates to the
>> Address object ie objUser.setCity("Dundee") and in User.cfc have the
>> method setCity() doing variables.objAddress.setCity()
>
>
> Let the Law of Demeter be your guide:
> http://en.wikipedia.org/wiki/Law_of_Demeter
>
> It says you should go for option b, if I understand it correctly. However, I
> seem to have a slight preference for option A at times, and I can't recall
> when it has brought me trouble. I assume it has brought trouble to someone at
> some time or another, because we wouldn't see a Law of Demeter otherwise, but
> following it blindly is like the story of the angry monkeys:
>
> A few monkeys were put in a room with a stepladder and a banana that could
> only be reached if the monkeys used the stepladder. However, when a monkey
> would climb upon the stepladder, all the monkeys would be doused with water.
> Then new monkeys were introduced and when they tried to use the stepladder,
> the other monkeys would get angry and beat him up. Eventually, the room
> contained none who had been doused with water, but the monkeys who had been
> beat up for using the stepladder were still refusing to allow new monkeys to
> get the banana.
>
>
>>
>> 2) If I want to save the address using a DAO how should I approach it?
>> At the moment I have a UserService cfc that calls the save() method in
>> the UserDAO. I don't like the idea of UserDAO having to use the
>> AddressDAO to save the address as it seems I'm giving it a
>> responsibility it shouldn't have. I thought about the service layer
>> and would run UserDAO.save() then call
>> AddressDAO.save(objUser.getAddress()). This also seems wrong as I feel
>> I'm losing the benefits of the composition in the first place by
>> calling 2 save() methods in 2 DAO's for the composed bean. Should
>> UserDAO itself be composed of an AddressDAO so it is set up in the
>> same way as the Beans?
>
> I don't know the "proper" way to do this, but I would opt for how you have it
> currently. But, I'm not as into this service thing as I probably should be,
> so I fully grant that I may be giving you the wrong advice for your situation.
> =)
>
> Regards,
> Sam
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
