I'm going for the injection through the Repository. Is there a way for Windsor/MicroKernel to inject dependency (via property injection ofc) of an already instantiated object or I have to inject dependencies one by one?
P.S. Leave aside the discussion about Entities and DI, the patch to support NH2.1 is still there :) Il giorno 06/gen/09, alle ore 17:03, Markus Zywitza ha scritto: > > 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 -~----------~----~----~----~------~----~------~--~---
