0

I am going to develop enterprise application and have many project in solution problem is suppose 1- Webapi project 2- Services project 3- DataModel project

Webapi project calls services project and Services project calls DataModel project problem is I have to add both(Services, DataModel) projects dll in Webapi project and add all classe and interface in Startup class like

public void ConfigureServices(IServiceCollection services) 
{ 
  services.AddTransient<IDocConverterProAuth, DocConverterProAuthentication>(); 
  services.AddTransient<IFileConverter, FileConverter>(); 
  services.AddTransient<IFileConversionService, FileConversionService>(); 
}

But I have 50 project and hundreds class. I have to add all references in Webapi project. I thing it is not correct way because DataModel project is not used in Webapi project only Services project uses DataModel project so resolve dependency in Services project so kindly guide me how I possible my development environment is

1- Visual studio enterprise 2017 2- .net core 2.1 3- C#

Chetan
  • 6,711
  • 3
  • 22
  • 32
Akmal
  • 11
  • 2
  • Autofac (DI container) allows you to separate registrations into modules. Perhaps somebody has built something around the .NET Core DI ServiceCollection to achieve a similar goal? Alternatively, you could change `ConfigureServices` to return an `IServiceProvider` and use a different DI container that implements this. – ProgrammingLlama Feb 13 '19 at 06:46
  • First of, read about composition root in DI. The application should be bootstrap as close to the application entry point as possible, in your case that is the web api project. Secondly, you can register all interfaces and instances via an assembly. look at this answer https://stackoverflow.com/a/35490207 – Marcus Höglund Feb 13 '19 at 06:59
  • The common pattern für the .NET Core DI is to use extensoin methods on `IServiceCollection` to do your registrations and call it like `services.AddXyz()` – Tseng Feb 13 '19 at 07:42

1 Answers1

0

I had this kind of scenario longtime back (like 2010), the solution I chose in that case was scanning the assembly to find all the contracts, giving contract implementation a unique name, for example: abc.business.interfaces.dll and the corresponding implementation was in abc.business.dll

Using such nomenclature, i was able to identify implementation assembly for corresponding interfaces and then register them in the container for DI.

So if you don't want to write every DI injection, you have to write such implementation. I think there are also some ready-made solution available, but I haven't used such solution so can't recommend.

mukesh joshi
  • 584
  • 5
  • 19