Me too. On Tue, Jan 6, 2009 at 12:49 PM, Ayende Rahien <[email protected]> wrote: > 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/ >> >> > > > > >
-- 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 -~----------~----~----~----~------~----~------~--~---
