[kforge-dev] Dependency Injection in Domain Model, Kforge

[John Bywater]

Rufus Pollock wrote:

>> Sorry for the long email, and thanks for making it this far. I'd love 
>> to hear
>> your input and thoughts on this. Do you have any experience with any 
>> of the
>> other python DI frameworks? What do you think of DIPPY? Do you think it 
>
>
> John was the man who wrote the original ioc code so he is probably the 
> better person to comment here.


I think it's almost certainly a big improvement to introduce dependency 
injection. One of those other python frameworks isn't unit tested, and 
one uses XML which we probably don't want. So I think we should feel 
happy to use our own interpretation of the pattern, and reserve our 
judgement about selecting a third party module perhaps until we 
understand more about how this pattern works?

As Fred Brooks said the conceptual components are taking most of the 
time, so it was that we've been thinking about dependency injection 
since summer 2005. It took David about two days to write the module the 
other week, so we shouldn't spent too much more time working out whether 
or not to use it. :-)


>> would
>> be good to refactor DM to us constructor injection or is it just fine 
>> how it
>> is?
>
>
> Having read your mail and the linked references I think your 
> suggestion for a modification makes a great deal of sense. Of course 
> John is more knowledgeable in this area than I would defer to him to 
> have the final word on this but my feeling is that this is a 
> refactoring/improvement that should be done.


There will be a few corners to go round, as dependencies are currenly 
mostly defined on the class, and so things happen much earlier than will 
be the case with constructor injection. But we should be able in a 
progressive manner to replace all dependency on dm.ioc. Of course, we 
may wish to substitute a more appropriate container afterwards if we 
find one. But that would be fairly straight forward.

All best wishes,

John.