No it would rather be: var acc = repo.CreateAccount(customer); acc.SomeOperationThatDependsOnAService();
Creating entities in client code is a code smell in itself IMHO. -Markus 2009/1/6 hammett <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
