1

I’m looking for a DI solution to help me manage object associations for situations where the object associations need to be set based on other member values within the same object.

enter image description here

So, given an object association where an Employee object has an AddressId Property and related Address association Property how can I externally manage these associations in a way that allows each class to remain loosely coupled?

My first attempt was to use an IoC container. I stopped using this approach after realizing I would need to extend my container so that it is able to resolve type instances based on decision logic stored in IoC configuration – that just seems like a bad idea. (Injecting the container into the repository would work but would break my compositional root so that’s off the table too.) With that said, I don’t think this is a job for an IoC container – convince me otherwise.

I did some research and found a paper by Andy Bulka called Relationship Manager. Bulka's design calls for a mediating class that manages the associations. I’m not sure if this is the best approach.

I’m sure someone in the community has tackled this before. What are the DI best practices related to this design problem?

  • 1
    If you're talking about associations between domain objects, ORMs have a Relationship Manager built into them which will build a tree of objects for you in the exact manner you describe. Is there a reason you can't use an off the shelf solution like that? – Steve Wilkes Jan 17 '12 at 21:58
  • 1
    +1 absolutely true. DI is not about assembling relations between entities like Customers and Address – Sebastian Weber Jan 18 '12 at 06:40
  • 1
    Related: http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec – Steven Jan 18 '12 at 10:47
  • @Steve Wilkes. Unfortunately, I'm pulling data from several different sources. With that said I'm following more of a DDD structure for my application. –  Jan 18 '12 at 14:29
  • @Steven: Thank you still trying to take in the implications of Greg Young's DDDD Paper http://abdullin.com/storage/uploads/2010/04/2010-04-16_DDDD_Drafts_by_Greg_Young.pdf –  Jan 18 '12 at 21:35
  • You have a direct association between `Employee` and `Address`. I don't see how this can be decoupled unless you break that association and rely on sharing the address identity via `AddressId`. In any case, if you reference `Address` from `Employee`, that's coupling by design. –  Apr 18 '12 at 22:52

0 Answers0