It's not that entities should not have dependencies injected; DI is a valuable consideration for entities. But for injecting them via an IoC-Container, you have only two choices: 1) Using a ServiceLocator-Pattern, creating external dependencies on the entity 2) Let the IoC-Container serve the entity, what it is not build for.
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. -Markus 2009/1/6 Michele Cantelli <[email protected]>: > > Probably you're right, the implementation described by Fabio Maulo > sounds like an hack also in my opinion. > > Anyway the discussion shifted to an interesting point. > > So the answer is: why Entities shouldn't have their dependency > injected and Services can? Entities does have behavior, right? So why > I can't have a Strategy in a Entity and inject the real > implementation? Why I'm > forced to move this dependency (and generally the behavior) into a > Service? > > Eric Evans states that a good Service has three characteristics and > the first is: "The operation relates to a domain concept that is not a > natural part of an Entity or Value Object". > Isn't right to have something like invoice.CalculateTotal() instead of > invoiceService.CalculateTotal(invoice)? > > Ofc I'm not saying to put all the Entities into the container nor to > move and split the whole behavior of a Entity into Strategies but when > I found a behavior which I need to replace (think about Multi-Tenant > Application) why not? > > Again, back to the implementation detail, as I said, using the > ReflectionOptimizer sounds very hackish, I'm considering to move the > responsibility of the injection in a Factory so there are no need to > have the Entity in the container. > > Il giorno 06/gen/09, alle ore 08:46, hammett ha scritto: > >> >> That really doesnt make it. Entities dont belong on ioc container. >> When you create such dependency you'll need to have factories (or as >> you suggest, repository) everywhere you need a new entity instance. >> The viral nature of this dependency leads to incredible headaches, if >> you - like myself - dont want to rely on hacks or statics. >> >> But I guess this is something that ppl should feel in their bones. >> Writing about it wont cut it. >> >> >> On Mon, Jan 5, 2009 at 11:40 PM, Markus Zywitza >> <[email protected]> wrote: >>> >>> Agreed, handling that in a nice RepositoryImpl is way cleaner and >>> instantly understandable. >>> >>> -Markus >>> >>> 2009/1/6 hammett <[email protected]>: >>>> >>>> IMHO he has no idea how that can be troublesome. >>>> >>>> On Mon, Jan 5, 2009 at 7:11 PM, Michele Cantelli <[email protected] >>>> > wrote: >>>>> Any news about? >>>>> >>>>> I'm stressing about this because I found an interesting feature >>>>> in NH2.1 >>>>> about Entities and Dependency Injection which I found quite >>>>> useful in many >>>>> scenarios. You can read more >>>>> here: >>>>> http://nhforge.org/blogs/nhibernate/archive/2008/12/12/entities-behavior-injection.aspx >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 -~----------~----~----~----~------~----~------~--~---
