Hi Tom, Honestly I don't really see the circular dependencies as a problem per se, so I haven't really thought it through, but in the general case I have n-business objects any of which might have relationships with 0..m other business objects.
I describe my business objects and their relationships using configuration data and then just generate all of the service, DAO, controller and bean classes, wiring them up automagically based on generalized architectural rules so if I wanted to start injecting service classes into DAOs for some reason, I'd change one line in my bean config and it'd do that for all business objects. I also parse the relationships to automagically wire dependencies so if User has-many addresses, as well as handling all my ORM concerns that one line of configuration ensures that AddressService gets automagically injected into UserService without me having to tell it to do that (I've already told it that there is a relationship so it should be smart enough to wire itself up to make that work). Given all that I'm sure there would be a way of implementing your approach for the generalized case of n business objects each of which may have m relationships to other business objects, but I think it'd be adding complexity where I don't really feel I have a problem to solve. Make sense? Best Wishes, Peter On 6/20/07 11:38 AM, "Tom Chiverton" <[EMAIL PROTECTED]> wrote: > On Wednesday 20 Jun 2007, Peter Bell wrote: >> I have circular dependencies all the time. They are a valid situation. Most >> commonly I see them between service classes where (for example) UserService >> and AddressService need to access each other. > > In which I'd love to know why you can't do the same trick as I suggested to > the Domain/DomainEmail problem...
