If I need to do this, I usually have the entity take the deps through the method parameter, instead of storing it inside the entity
On Tue, Jan 6, 2009 at 9:31 PM, hammett <[email protected]> wrote: > > On Tue, Jan 6, 2009 at 8:03 AM, Markus Zywitza <[email protected]> > wrote: > > A better option is having services and strategies as properties in the > > entity and letting the repository inject them manually. The repository > > is the right object for serving entities (that is its single > > responsibility)and it can itself be served from IoC-Container, as it > > is non-persistant. That way, the strategy can come from the > > IoC-Container while also decoupling the entity from it. > > So you're saying that entities would have a dual state. I can have > something like > > var acc = new Account{Owner = customer}; > acc.SomeOperationThatDependsOnAService(); // exception > accRepository.Add(acc); > acc.SomeOperationThatDependsOnAService(); // works > > Also, replicating dependencies on a distinct player feels like a > smell. I for one hardly have my repositories having dependencies. > But I agree that in the great scheme of things, it's the less > problematic approach.. > > -- > Cheers, > hammett > http://hammett.castleproject.org/ > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
