Dependency Injection: How to Enter When Using a Multiproject Solution

Question

I hope this question is not too stupid, I am trying to catch more advanced programming principles and thus have been trying to get used to Injection Dependency using Ninject.

So, my model is divided into several different DLL projects. One project defines model specifications (interfaces), and a couple of others implement these interfaces. All model projects must use some kind of database system, so they all need access to another .dll, which implements all my database logic. It is important that they all can access the same instance of my database object, so if it weren’t enough just to create one instance for each model.

I'm not quite sure how to achieve this using dependency injections. My first thought was to create a separate DI project and link all the interfaces to their respective implementation, so the DI project needed links to all other projects (model and implementation interfaces, database system, etc.). Again, models need access to the DI project because, for example, they will need to query the database system from the DI (Ninject) system. Of course, this will create a circular link (link the DI project with the model and model to the DI project), so this is not possible.

In short, I need a programming pattern that allows me to associate model interfaces with their implementations, but also allows model implementations to request other Ninject dependencies, for example.

IModel1 -> Model1 IModel2 -> Model2 (different project) IDatabase -> Database (different project) Model1 -> request IDatabase -> get Database instance Model2 -> request IDatabase -> get the same Database instance 

I would be glad to receive a couple of suggestions, at the moment I'm stuck out of ideas;) Thank you!

Answer 1

models need access to the DI project because, for example, they will have to query the database system from the DI system (Ninject)

When you use dependency injection, models do not need to access the DI infrastructure, as it is a DI environment that introduces dependencies. Model objects should not request a DI container. When your objects request a container for dependencies, it is not called dependency injection, but a service locator. Locator is considered an anti-pattern .

My first thought was to create a separate DI project

When you have one application (i.e. a web application), the usual task is to fully configure the DI container in the final application, as close as possible to the application entry point. This is called the composition root .

All project models must use some kind of database system, so they all need access to another .dll, which implements my entire database. Logic

Try to create POCO model / object objects (plain old CLR objects), or at least ensure that these objects do not need to reference any other project, which will greatly simplify your architecture (and testing).

Answer 2

Use a Ninject with the Register Resolve Release template from Composition Root .

Answer 3

The client application will use Ninject to enter actual database implementations and models.

Therefore, the client application must reference the database, database, model and imodel projects.

Database and database projects must reference the model project because the methods return model objects or collections of model objects. Look at the repository template .

Your model should not refer to any of your projects.