Dependency Injection?

[DavidRieman]

Although I don't think we should currently pursue DI for WheelMUD, I've collected notes from the archives for context on this current stance. (TLDR; MEF is not DI but solves related needs well enough that DI is no longer attractive to pursue too.)

This thread contains restored content from prior forums; see #134 for details.

---

[Jan 2011]

(There was a basic proposal to use Inversion of Control [IoC] containers / dependency injection [DI] across WheelMUD...)

I don't understand. If one system has a dependency on a lower level system, a compile-time dependency is appropriate. MEF already eliminates dependencies going the other way around (like where our CoreManager used to know about all the Managers directly, but now it doesn't.) So basically I feel MEF already fills this need, where appropriate, WRT our project. Do you have any concrete examples showing otherwise?

A couple related thoughts IMO, mainly around the direction of Systems as I see us headed:

• any systems which don't make sense to have duplicates of should be singletons.
• if your thing/system uses another system, refer to it through the system's .Instance - this is a one-way street.
• callbacks and events are a form of IoC which we already use.
• our systems shouldn't have a 'start' and 'stop' method - this puts the onus on the user of the object to know when/how to do that. Instead I think:
  • our systems should do their startup at instantiation time - if they rely on another singleton system which isn't started up yet, their usage of that .Instance inherently causes a correct instantiation order w/no fuss.
  • handle any appropriate system pausing/locking during Recompose (where IRecomposable) rather than .Stop and .Start of the system.
  • an instruction to 'stop' a system shouldn't be needed (shy of program shutdown; dispose or destructor is appropriate there).

To expand a bit, I'm a bit biased because I have yet to see a DI setup where the benefits outweighed the day-to-day costs. If we're going to break my ability to, for instance, browse-to-definition on a component I'm trying to use, or have compile-time verification of something as common as a class name, then there better be really really good reasons which outweigh those sorts of daily impediments.

Breaking down two-way dependencies so things can live in appropriately layered assemblies, and recomposing updated components at runtime, are a couple good reasons IMO (but of course both are already covered with MEF).

On singletons: Agreed. All top-level systems need to follow this pattern.

One point that we are missing here is that part of WM's charter is to give marketable skills to its participants. I've talked with over 46 software managers in the last 11 months. One thing that was clear is that all of these companies are moving into using MEF, IoC containers, Unit Testing, and one of the Model-View frameworks (MVC, MVP, MVVM). Our NVelocity templates are a form of Model-View.

I agree that the singleton behavior would cause the class to instantiate correctly. However, this model breaks down when you have a dependency tree that goes further than that. We would still need to create systems in a specific order. The old implementations of IoC didn't handle this very well. The new IoC stuff handles dependencies recursively. All that is needed is to tell the container what are the top-level dependencies, and it does the rest.

The start and stop blocks are what make debugging a LOT easier. I haven't seen anything so far that changes my mind on this. However, I'm willing to look at doing away with it, if I find that it is not onerous to debug. I don't want us indulging in Not-Invented-Here arguments. There are a lot of useful frameworks out there, and I don't want us trying to re-invent the wheel.

Again, MEF is a discovery mechanism, not a DI one. It will only resolve first-level dependencies because those are implicit. It will not resolve Nth level dependencies inside an instantiated class.

I didn't claim that MEF is an "IoC container". (I was careful not to word it that way as I have seen the blogosphere going nuts over that differentiation and yet still fail to efficiently educate people on when/how/why to use these techs, but I digress.) I am however thinking that MEF helped sufficiently break down the underlying problems you alluded to: The two-way dependencies of the CoreManager and the other system managers themselves. Proper self-instantiation instead of user-prodded instantion via Start() helps make these systems stand on their own even better and utilize their own dependencies properly - it shouldn't be on the admin to figure out what uses what and ensuring that the systems are listed/instantiated in the correct order - that should be self-enforced by the singleton pattern. Our systems startup order used to be super fragile; trying to alpha-sort the Start calls or whatnot, since it wasn't made clear even w/comments that order was important, or what had to be before what... was a recipe for disaster. I've cleaned it up since with the MEF auto-discovery via GetLatestSystems.

Interfaces aren't required to decouple various systems; there are lots of techniques to decouple systems. Callbacks, events, and MEF for instance, don't require interfaces and can all be used to help decouple systems.

It will not resolve Nth level dependencies inside an instantiated class.

What do you mean? To go along the lines of the wikipedia car analogies... do you mean we have a need for the ability to specify "I want a car, which has radio A (with media features B, C and D), and has engine E (which contains F cylinders and spark plugs G), and ..." all at the top level?

part of WM's charter is to give marketable skills to its participants

Yes, but we need an actual reason beyond that to use a tech. We're not going to be adding, say, DirectX to the project just because those skills are marketable. Do you have a concrete example how DI helps our specific project?
Anyway, I'm not really trying to be difficult, I just don't really get it yet. I can probably be swayed in time. It just feels kind of like a shiny solution in search of a problem right now.

I've been crazy busy, and only had time to skim through the website. I'll see if I can do more this weekend.

---

[ed. update 2021] Well I can't find any further replies in the archives. If anyone reads this and thinks we should really add DI to solve some observed problem in the source, this may be a good place to resurrect the conversation.