We Keep Coding

Dotnet organizing dependency injection registration and project seperation

Have a project structure where I have a couple of layers
Api
Bll
Dal
Utility
When say a order request is received by the Api there is a couple of steps that we need to take.
Like:
Validate the input
Save the customer
Save the order
Validate payment
Save final order status
All of these require different classes from the Bll
And the classes inside the Bll requires classes from Dal and maybe other Bll or from Utility.
So now inside the Api I need to register the whole chain of what might be needed like
Register<IValidateService,ValidateService>()
Register<ICustomerService,CustomerService>()
Register<ICustomerDatabaseService,CustomerDatabaseService>()
Register<IUtilityService,UtilityService>();
Maybe all of the above just to get the CustomerService working, and then we need to do this for a lot more services and I will have to reference the Dal layer inside the Api layer.
And in the long run I feel that everything will become really bloated.
Would be good if I could just Register the CustomerService and then that will register it's dependencies by itself or something.
Maybe it is fine to have the entry level to be aware of everything?
Any ideas on how to solve this or am I overthinking things?
Thank you

My suggested solution for auto-registration is the following:
Use Autofac.
Create a public DependencyModule class derived from Autofac.Module in your Api, Bll, Dal and Utility projects.
Override the Load method and register only types that are in that project.
In your startup project (Api) use my nuget package to automatically discover and register all your DependencyModule classes into the DI container.
At the end you will have something like this:
Utility
DependencyModule.cs - registers all the utility types that need to be injected.
Dal
DependencyModule.cs - registers all the DAL types (e.g. DbContext) that need to be injected.
Bll
DependencyModule.cs - registers all the BLL types that need to be injected.
Api
DependencyModule.cs - registers all the API types (if any) that need to be injected. E.g. filters, etc.
In Program.cs or Startup.cs you register only my Autofac module that will discover and register all your modules above.
See my example solution's description and implementation.
This way each injectable type registration is done in its own assembly and dependent services do not need to worry about it.
Alternative solution - uses Microsoft DI
Instead of Autofac modules you can create extensions methods for IServiceCollection type in each of your project and register the types that are in that project.
Then in your Program.cs or Startup.cs just call each extensions method.
At the end you will have something like this:
Utility
IServiceCollectionExtensions.cs - registers all the utility types that need to be injected.
Dal
IServiceCollectionExtensions.cs - registers all the DAL types (e.g. DbContext) that need to be injected.
Bll
IServiceCollectionExtensions.cs - registers all the BLL types that need to be injected.
Api
IServiceCollectionExtensions.cs - registers all the API types (if any) that need to be injected. E.g. filters, etc.
In Program.cs or Startup.cs call each of the extensions methods.
Note
Actually you can combine MS DI with Autofac so that you can enjoy the advanced features of Autofac and use specific extension methods for IServiceCollection at the same time.
In that case you should know that the order of registrations is this:
MS DI registrations: ConfigureServices() method
Autofac registrations: ConfigureContainer<T>() method
All the MS DI registrations will be populated into the Autofac container.

Dependency injection should be done at the application layer, which means the application must specify (effectively, choose) all of the dependencies in order for it to work correctly. This does mean it will be "bloated" in the wiring/startup phase, and does mean the app layer will have to deal with dependencies it might not normally care about.
That said, there's nothing wrong with your library code providing sane base implementations and wiring of these to alleviate the app layer's burden of figuring out what to wire up.
That means you can do one of
add the statements for registration manually and explicitly in your startup (total control, and extremely obvious how things are setup)
create a convenience method that contains common wiring in your library (less control, but less code to deal with when wiring). This is common in ASP.NET (see the AddXxx() and UseXxx() patterns).
discover dependencies. This uses reflection (usually) to find the implementations of all the dependent interfaces, and auto-register them). This is usually from a third-party like AutoFac. It's not built in to .NET.

Dependency Injection Container for each Class Library

So, this is the first time I'm dealing with DI, please correct me if I misunderstood the whole DI thingy.
These are few of my projects:
Web Application/ Web API Project - Depends on Service Class + inject Automapper (Configuration only applicable for current project)
Service (Class Library) - Depends on Data Class + inject Automapper (Configuration only applicable for current project)
Data (Class Library)
My intention was to have each project having its own DI container (says Unity DI). I'm not sure that each project can have its own DI container.
I have read some of the article, showing that it cannot be done (not sure if i interpret them correctly) but I'm not sure why?
If it cannot be done, can anyone explain it and how can I achieve this and I doesn't want to register the classes in Data Layer in the Application Layer DI.
If each project can have its own DI, when registering the IMapper as instance will it override IMapper of other layers?

My intention was to have each project having its own DI container (says Unity DI). I'm not sure that each project can have its own DI container.
As explained here, you should compose all object graphs:
As close as possible to the application's entry point.
This place is called the Composition Root:
A Composition Root is a (preferably) unique location in an application where modules are composed together.
In other words, the only place that you should use your DI container and configure your application's dependencies is in the start-up project. All other projects should be oblivious to the container and should purely apply Constructor Injection.
I have read some of the article, showing that it cannot be done
It can be done, but you shouldn't.
If each project can have its own DI, when registering the IMapper as instance will it override IMapper of other layers?
This problem goes away if you apply the Composition Root pattern. In the Composition Root you have full control over which component gets which dependency.
PRO TIP: Read this book.

DI container for 2 layers

I'm trying to design WebApi application with using IoC like Ninject. I have the following layers(3 projects):
Domain(Repository) layer
Service
Web API application core
The Repository layer has interface IRepository<T> and a few implementations of it. And in the Service also exists interface IService<T> with a two different implementations.
Could you please advise me should I use DI container (Ninject) in WebApi project to bind IService<T> and ServiceConcrete<T> and DI container in the Service project to bind IRepository<T> and RepositoryConcrete<T>?
Or maybe should I use only one DI in WebAppi project?

A practical way I have found to set up Ninject modules can be found below.
Overview
Create an assembly called DependencyResolution
Create the Ninject modules (that you will utilize in your WebAPI project)
Have only this DependencyResolution and your Domain projects referenced in your WebAPI project
Initalize/register your modules in NinjectWebCommon.cs
Details
Should be easy as create a project, add Ninject as reference from NuGet for instance.
Add new class file(s) to this project named after the modules you want to create like: ServiceModule.cs, RepositoryModule.cs, etc.
Create your Ninject module(s). For detailed instructions on this you can refer my answer on this.
In your WebAPI project, you add reference to this just created DependencyResolution project and your Domain project.
Initializing/registering your just created module(s) in the WebAPI project's NinjectWebCommon.cs as:
private static void RegisterServices(IKernel kernel)
{
var modules = new List<INinjectModule>
{
new ServiceModule(),
new RepositoryModule()
};
kernel.Load(modules);
}
I will also try to address another concern that is loosely related to your question. I think your current layering setup would need a bit to be changed.
The basic and probably my biggest problem with your layers are that you mix up and therefore tightly couple the Domain and Repository which is clearly an infrastructural concern.
I would suggest to re-architect your layers as:
Domain
Services
Infrastructure (Repository implementations could go here for instance)
Dependency Resolution
WebAPI
Do not forget that your Domain layer should not have any idea about infrastructural details like Repository, else you are going to tightly couple your domain with unneeded implementation details.
EDIT: From the comments I see that you have some concerns about where to place and how to name things which is obviously one of the hardest things in programming.
So my thoughts on clearing this confusion up are:
Layer: is a logical separation or collection point of classes, methods, etc. that those belong together.
Each layer can consists of multiple projects or assemblies. So if you want to categorize your projects into layers, you could create directories in your solution named about your layers and place the individual projects inside these directories. It's really just a matter of taste in the mouth, take it just as a tip.
Example structure
Solution root
Core directory
Domain assembly: the root of you domain where you have your business or domain entities AND the all the interfaces that your domain is using.
Domain services assembly (just could be in Domain assembly as well)
Services directory
Application services assembly: for example an example this assembly houses services or facades that spans operations accross multiple domain entities or aggregates, etc.)
Infrastructure directory
Repository assembly: this is where you have the implementations of your EF repositories
Custom logging/email/whatever else assemblies or implementations that doesn't belong to the domain.
DependencyResolution assembly: this is the place of your NInject modules and all IOC container related wirings.
UI directory
WebAPI assembly
Asp.Net MVC assembly
Summary
The Dependency Resolution project has references to any needed assemblies (Domain for interfaces, Services/Infrastructure for their implementations) and wire them altogether for later use.
The WebAPI project would only need to have reference added Domain and Dependency Resolution so then you could just ask for your interfaces in your WebAPI methods/functions public constructor and Ninject will do the dirty job for you behind the scenes.
Please don't forget that this is just an easy quick 'n dirty architecture suggestion of mine, without knowing your exact requirements and use cases.

If I understand your question, you're having troubles configuring your Repository layer because your config code is in your application layer, which probably only references your service layer (which in turn references your repository layer). What I've done in order to get around this is first create your configurations in modules (these can live on any layer, but you must reference Ninject)
For your repo layer:
public class RepoNinjectModule : NinjectModule
{
public override void Load()
{
Bind<IMyRepo>().To<MyRepo>();
}
}
create a similar Module in your service layer:
public class ServiceNinjectModule : NinjectModule
{
public override void Load()
{
Bind<IMyService>().To<MyServce>();
}
}
Then, in your application layer, you can load the modules dynamically (this is what NinjectWebCommon.cs looks like):
private static void RegisterServices(IKernel kernel)
{
kernel.Load(AppDomain.CurrentDomain.GetAssemblies());
}
More info on modules: https://github.com/ninject/Ninject/wiki/Modules-and-the-Kernel

ASP.NET MVC Project EF Repository Pattern

If I use the Repository Pattern in an ASP.NET MVC Application I need DI to let the program know, to interface the classes must be mapped. If I implement Unity I need to add the DAL project to my MVC project, and then register the types in the global.asax.
In my mind, I think it's bad to add the namespace of the DAL Layer to the MVC project, there is a business layer also in between. I think, it would be beautiful to inject the DAL classes in the business layer and only the business layer mappings in the MVC app.
What's the way to go here? Do you have suggestions?
UPDATE:
To make it clear to me. In the service layer, there are only DTO's and the DI for the business and data access layer. In the service layer I map the DTOs to the domain model. What I don't understand is, how can I call the business layer methods then?

If you want to be pragmatic, a true 3-tier architecture requires a service layer. Between the service and MVC are Data Transfer Objects (DTOs). The service layer hides both the DAL and the business layer.
If you set it up like this, the MVC itself knows nothing about DAL, only DTOs and Service (contracts).

Even if you don't use a distinct service layer, you can accomplish what you want, which is to decouple the MVC application from the DAL project using DI.
The way to do this is to add a couple of projects/assemblies in between that wires up your IoC container with specific instances of the interfaces you have defined.
I typically use this naming convention:
MyCompany.MyProject.Infrastructure
MyCompany.MyProject.Abstract
Your main MVC project would then have a reference to your Abstract and Infrastructure projects. Your Infrastructure project would have a reference to the Abstract and instance specific projects like the Business and DAL projects. Within Infrastructure project you wire up the dependencies.
You'll have to setup a mechanism for your MVC project to bootstrap your IoC in the Infrastructure assembly. You can do that in your global.asax or as an App_Start method and call a Registration class within your Infrastructure assembly.
We use StructureMap, but the concept is the same. Here's some sample code.
In your MVC App, create a App_Start method to setup the DI.
public static class StructuremapMvc
{
public static void Start()
{
// Create new Structuremap Controller factory so Structure map can resolve the parameter dependencies.
ControllerBuilder.Current.SetControllerFactory(new StructuremapControllerFactory());
IContainer container = IoC.Initialize();
DependencyResolver.SetResolver(new StructureMapDependencyResolver(container));
GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver(container);
}
}
In your Infrastructure assembly, wire up the dependencies.
public static class IoC
{
public static IContainer Initialize()
{
ObjectFactory.Initialize(x =>
{
x.Scan(scan =>
{
scan.TheCallingAssembly();
scan.WithDefaultConventions();
});
x.For<IRepositoryNum1>().Use<Num1Repository>();
x.For<IRepositoryNum2>().Use<Num2Repository>();
x.For<IRepositoryNum3>().Use<Num3Repository>();
});
return ObjectFactory.Container;
}
}

You should use DI to inject the Domain/DAL interfaces into your constructors. This has a lot of upside including allowing you to moq your interfaces when you write your unit tests. You can use Autofac to handle the injection.

Not understanding where to create IoC Containers in system architecture

Say I have the following 4 .net assemblies:
Winforms UI
Business Logic
SQL Server Data Access (implementing an IRepository)
Common Interfaces (definition of IRepository etc.)
My business logic (2) makes calls to the data access layer (3) through IRepository (defined in 4) using constructor dependency injection. However when I ceate a business object I need to pass in an actual repository. I do this by having a singleton class in my business logic layer return the currently in use concrete object implementing IRepository. I am coming to the conclusion that this is a bad thing, as my business logic layer now has to reference 3 as well as 4.
I think I need a IoC Container but the question is where I create/put it as it seems that wherever I create this (1 - UI)? will also need to hold a reference to 3 (SQL Server Data Access). Am I not just moving the problem rather than achieving actual decoupling?
Do I create the IoC Container in the UI. Or expose it through another new assembly.
(I'm using C#, .net 3.5 and AutoFac)
Thanks.

IoC container generally should be created in the host project (application entry point). For the Windows.Forms application that's the exe project.
Generally in simple solutions (under 10 projects), only a host project should have a reference to IoC library.
PS: Structuring .NET Applications with Autofac IoC

When registering components there are several possibilities:
Registration in code:
directly
Problem: you have to reference everything ( you are here)
indirectly
Problem : to find out what has to be registered
Solution:
use attributes
use marker interface as IService
use conventions (see StructureMap)
Registration with configuration file:
let the container do everything
read the file yourself

Top level is a way to go (UI, as Rinat said).
Now as for references, simplest way is just to go over all assemblies in the current folder and use some convention to get the services out. Attributes work fine, putting registrar classes in each assembly works fine, whatever suits you. The code for extracting everything should probably be in a separate assembly, unless your IoC framework already does that.

The module distinction and the "scopes" defined by the modules exist mostly at compile-time. In the run-time it's all one big mess ;) This is used by most IOC containers and they don't really care about where they are located. The IoC container for a web-app will typically be created at the outermost level (very close to the web-container itself).

It's true that you could create it anywhere, but I'd introduce an extra layer, let's call it 3.5.
Your current 3 would be where your IoC resides for Data Access - this would become a wrapper for your actual DAL. Based on your config, 3 would create either a mock repository or a concrete one.
So 2 still references 3, but it's just an interface to the actual DAL which is configured through your IoC framework.
Alternatively, you could roll your own 'el-cheapo' IoC - change your Big Ugly Singleton to a Static Gateway - Abstracting IoC Container Behind a Singleton - Doing it wrong?