Implementing Dependency injection across multiple solutions

Question

We have a landscape with 15 solutions, where each solution contains many projects of its own. All solutions however, share some common project called "Model". Since each solution however, wires its own object graphs, this causes the registrations for the Model project to be duplicated 15 times.

What's the best way to prevent this duplication?

Example:

Solution-A

Model

public class Account
{
    public Account()
    {
        var a=Resolve<IEmailer>();
    }
}

The addition of above code in constructor forces me to register the dependencies in all start-up projects of the solutions if they refer the above class. Some solution need Account class but not IEmailer but still it need to inject IEmailer in that solution.

Steven · Accepted Answer · 2014-10-24 08:14:48Z

4

Registering everything in the start-up project is actually a good thing. This common place is called the Composition Root and it allows you to minimize the number of references between your projects, as explained clearly here.

Another thing you should prevent is letting your code (anything except your composition root) depend on the DI library or an abstraction over your DI library. So instead of calling Resolve from inside your constructors, let any dependency a class has be injected into the constructor of that class. Example:

public class Account
{
    private readonly IEmailer emailer;

    public Account(IEmailer emailer)
    {
        this.emailer = emailer;
    }
}

This has many advantages over calling back into the container from within your code.

Do note though that your container is meant to build up object graphs of your services. If Account is an entity, resolving that from the container is not a usual and advised thing to do.

About the multiple-solution problem you're having: Since the shared project you're using, it might be good to prevent referencing this as a project, but make this an independent project with its own release cycle. Other projects can in that case depend on the assembly that you publish (for instance using your own local NuGet server).

But besides this, since this is a reusable project, make sure that assembly becomes a DI friendly library. If any bootstrapping should be done, and you want to prevent repeating this across solutions, create a separate bootstrapping-project. This bootstrapping-project refers to the reusable library and it references your Unity container. This way your library still stays completely independent to the used DI library, while you prevent duplicating bootstrapping logic throughout the solutions.

edited Oct 24, 2014 at 8:14

answered Oct 24, 2014 at 7:53

Steven

174k26 gold badges355 silver badges453 bronze badges

Sign up to request clarification or add additional context in comments.

5 Comments

Max_dev Over a year ago

Could you please give some example on bootstrapping-project.

Steven Over a year ago

@Max_dev: What do you want to know exactly?

Max_dev Over a year ago

I don't like to register the dependencies in all solutions. I am looking some best practice to avoid multiple registration across solutions. It would be much helpful if you direct me to some link which explains bootstrapping-project or anything related to this.

Steven Over a year ago

@Max_dev: A bootstrapping project is nothing special. It just contains the bootstrapping code that is specific to the "Model" project. You can simply create a public static Bootstrap(IUnityContainer container) method and the 15 composition roots of your 15 solutions will all call that Bootstrap method.

Max_dev Over a year ago

Thanks mate, sorry for late response. I implemented the solution like above.

Collectives™ on Stack Overflow

Implementing Dependency injection across multiple solutions

1 Answer 1

5 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

5 Comments

Your Answer

Sign up or log in

Post as a guest

Related