mbierlee / poodinis

Dependency injection framework for D with support for autowiring.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

feature request: context parameter

peerhenry opened this issue · comments

Feature request

As a developer I want to have the option of specifying a context as a string when registering dependencies so that I can register multiple interface implementations or subclasses without having to autowire any classes.

Motivation

Using a context, all classes can be kept loosely coupled from Poodinis at all times. Also, the developer can structure the dependency tree in one place rather than having to modify classes to specify autowire attributes.

Technical requirement (suggestion)

Associate the field

Registration[][TypeInfo] registrations

inside the class DependencyContainer with a context string, ie:

Registration[][TypeInfo][string] registrations

and overload the register method with a string parameter that allows the client to specify a context string parameter. Not specifying a string will result in registering in the "default" array. Resolving dependencies will first try to resolve within their registered context before reverting to the default context.

Could you give me a usage example? This request confuses me because there's already context registration in Poodinis, see https://github.com/mbierlee/poodinis/blob/master/TUTORIAL.md "Application Contexts"

This in combination with constructor injection helps you set-up dependencies without having to modify the classes themselves.

The goal would be to be able to register multiple implementations without using autowire. The word "context" may be a poor choice here because it's already used.

Example:
Suppose a class PetStore has a dependency on an interface Animal.

auto container = new shared DependencyContainer();
container.register!(Animal, Dog);
container.register!(Animal, Cat)("cats");
container.register!(IPetStore, PetStore).dependencies("cats");

auto store = container.resolve!IPetStore;

This setup will mean three things:

  1. The resolved store now has the Cat class injected.
  2. Any clients of Animal registered without .dependencies("cats") will get Dog injected.
  3. If PetStore has any other dependencies that were not associated with the string "cats", they will be resolved as usual.

Interesting idea. I would call them qualifier groups. Named qualifiers were on already my list, this would make the concept even more useful.

Even though implementation would be fairly straightforward, for the sake of not over-complicating the design I am inclined to close this request as a "won't do". The same can be achieved by setting up multiple dependency containers.