Keeping .NET Dependency Injection in Order
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Recently I started working on a new project using .NET Core 2.1 and I decided to use the SOLID principles and create a nice project structure.
It is a Web API project. Everything is working fine I use a lot dependency injection, most of the stuff is easy to test.
And that's the part where I have to register all my services. I am literally having hundreds of lines looking like this:
services.AddSingleton<...>();
or
services.AddScoped<...>();
I have one line for every service and for a small project it would be fine. However when I have hundreds of these it becomes on BIG mess. Basically the whole project is in a super nice order and there comes the Startup.cs that is full of services.AddX statements.
I was think of creating static classes with methods that register the services but that just doesn't look fine.
I will need to add more services in future and I can't just keep creating static classes or filling the old ones because I will end up with the same mess again and it will be more difficult for me to remember where am I registering a given service.
c# .net asp.net-core dependency-injection .net-core
edited Nov 24 '18 at 4:03
Foo
1
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
|
show 4 more comments
Recently I started working on a new project using .NET Core 2.1 and I decided to use the SOLID principles and create a nice project structure.
It is a Web API project. Everything is working fine I use a lot dependency injection, most of the stuff is easy to test.
And that's the part where I have to register all my services. I am literally having hundreds of lines looking like this:
services.AddSingleton<...>();
or
services.AddScoped<...>();
I have one line for every service and for a small project it would be fine. However when I have hundreds of these it becomes on BIG mess. Basically the whole project is in a super nice order and there comes the Startup.cs that is full of services.AddX statements.
I was think of creating static classes with methods that register the services but that just doesn't look fine.
I will need to add more services in future and I can't just keep creating static classes or filling the old ones because I will end up with the same mess again and it will be more difficult for me to remember where am I registering a given service.
c# .net asp.net-core dependency-injection .net-core
edited Nov 24 '18 at 4:03
Foo
1
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
2
I’m very much interested why you have hundreds of them. That seems like a gigantic project, or a problem in design.
– Sami Kuhmonen
Nov 23 '18 at 17:23
1
Assuming you do need them and can't break the project apart, you can use reflection to find the classes to register based on their names, attributes or interfaces they implement. That's how more advanced IoC containers like Autofac work. You can integrate Autofac with ASP.NET Core or you can implement a similar technique
– Panagiotis Kanavos
Nov 23 '18 at 17:34
2
You can have each group of services (assemly) export its own RegisterServices method. For fancy cosmetics, make it anAddMyStuff()extension method in theMicrosoft.Extensions.DependencyInjectionnamespace. SeeAddMvc()for an example.
– Henk Holterman
Nov 23 '18 at 18:11
1
Hundreds is not a lot. Not for the DI container at least.
– Henk Holterman
Nov 23 '18 at 23:50
1
However when I have hundreds of these it becomes on BIG mess - It shouldn't be a mess, because you will have one function where you execute hundreds of simple, clear and understandable lines of code.
– Fabio
Nov 24 '18 at 8:06
|
show 4 more comments
Recently I started working on a new project using .NET Core 2.1 and I decided to use the SOLID principles and create a nice project structure.
It is a Web API project. Everything is working fine I use a lot dependency injection, most of the stuff is easy to test.
And that's the part where I have to register all my services. I am literally having hundreds of lines looking like this:
services.AddSingleton<...>();
or
services.AddScoped<...>();
I have one line for every service and for a small project it would be fine. However when I have hundreds of these it becomes on BIG mess. Basically the whole project is in a super nice order and there comes the Startup.cs that is full of services.AddX statements.
I was think of creating static classes with methods that register the services but that just doesn't look fine.
I will need to add more services in future and I can't just keep creating static classes or filling the old ones because I will end up with the same mess again and it will be more difficult for me to remember where am I registering a given service.
c# .net asp.net-core dependency-injection .net-core
edited Nov 24 '18 at 4:03
Foo
1
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
Recently I started working on a new project using .NET Core 2.1 and I decided to use the SOLID principles and create a nice project structure.
It is a Web API project. Everything is working fine I use a lot dependency injection, most of the stuff is easy to test.
And that's the part where I have to register all my services. I am literally having hundreds of lines looking like this:
services.AddSingleton<...>();
or
services.AddScoped<...>();
I have one line for every service and for a small project it would be fine. However when I have hundreds of these it becomes on BIG mess. Basically the whole project is in a super nice order and there comes the Startup.cs that is full of services.AddX statements.
I was think of creating static classes with methods that register the services but that just doesn't look fine.
I will need to add more services in future and I can't just keep creating static classes or filling the old ones because I will end up with the same mess again and it will be more difficult for me to remember where am I registering a given service.
c# .net asp.net-core dependency-injection .net-core
c# .net asp.net-core dependency-injection .net-core
edited Nov 24 '18 at 4:03
Foo
1
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
edited Nov 24 '18 at 4:03
Foo
1
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
edited Nov 24 '18 at 4:03
Foo
1
edited Nov 24 '18 at 4:03
Foo
1
edited Nov 24 '18 at 4:03
Foo
1
1
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
asked Nov 23 '18 at 17:22
Kaloyan ManevKaloyan Manev
95111
95111
2
I’m very much interested why you have hundreds of them. That seems like a gigantic project, or a problem in design.
– Sami Kuhmonen
Nov 23 '18 at 17:23
1
Assuming you do need them and can't break the project apart, you can use reflection to find the classes to register based on their names, attributes or interfaces they implement. That's how more advanced IoC containers like Autofac work. You can integrate Autofac with ASP.NET Core or you can implement a similar technique
– Panagiotis Kanavos
Nov 23 '18 at 17:34
2
You can have each group of services (assemly) export its own RegisterServices method. For fancy cosmetics, make it anAddMyStuff()extension method in theMicrosoft.Extensions.DependencyInjectionnamespace. SeeAddMvc()for an example.
– Henk Holterman
Nov 23 '18 at 18:11
1
Hundreds is not a lot. Not for the DI container at least.
– Henk Holterman
Nov 23 '18 at 23:50
1
However when I have hundreds of these it becomes on BIG mess - It shouldn't be a mess, because you will have one function where you execute hundreds of simple, clear and understandable lines of code.
– Fabio
Nov 24 '18 at 8:06
|
show 4 more comments
2
I’m very much interested why you have hundreds of them. That seems like a gigantic project, or a problem in design.
– Sami Kuhmonen
Nov 23 '18 at 17:23
1
Assuming you do need them and can't break the project apart, you can use reflection to find the classes to register based on their names, attributes or interfaces they implement. That's how more advanced IoC containers like Autofac work. You can integrate Autofac with ASP.NET Core or you can implement a similar technique
– Panagiotis Kanavos
Nov 23 '18 at 17:34
2
You can have each group of services (assemly) export its own RegisterServices method. For fancy cosmetics, make it anAddMyStuff()extension method in theMicrosoft.Extensions.DependencyInjectionnamespace. SeeAddMvc()for an example.
– Henk Holterman
Nov 23 '18 at 18:11
1
Hundreds is not a lot. Not for the DI container at least.
– Henk Holterman
Nov 23 '18 at 23:50
1
However when I have hundreds of these it becomes on BIG mess - It shouldn't be a mess, because you will have one function where you execute hundreds of simple, clear and understandable lines of code.
– Fabio
Nov 24 '18 at 8:06
2
2
I’m very much interested why you have hundreds of them. That seems like a gigantic project, or a problem in design.
– Sami Kuhmonen
Nov 23 '18 at 17:23
I’m very much interested why you have hundreds of them. That seems like a gigantic project, or a problem in design.
– Sami Kuhmonen
Nov 23 '18 at 17:23
1
1
Assuming you do need them and can't break the project apart, you can use reflection to find the classes to register based on their names, attributes or interfaces they implement. That's how more advanced IoC containers like Autofac work. You can integrate Autofac with ASP.NET Core or you can implement a similar technique
– Panagiotis Kanavos
Nov 23 '18 at 17:34
Assuming you do need them and can't break the project apart, you can use reflection to find the classes to register based on their names, attributes or interfaces they implement. That's how more advanced IoC containers like Autofac work. You can integrate Autofac with ASP.NET Core or you can implement a similar technique
– Panagiotis Kanavos
Nov 23 '18 at 17:34
2
2
You can have each group of services (assemly) export its own RegisterServices method. For fancy cosmetics, make it an
AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace. See AddMvc() for an example.– Henk Holterman
Nov 23 '18 at 18:11
You can have each group of services (assemly) export its own RegisterServices method. For fancy cosmetics, make it an
AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace. See AddMvc() for an example.– Henk Holterman
Nov 23 '18 at 18:11
1
1
Hundreds is not a lot. Not for the DI container at least.
– Henk Holterman
Nov 23 '18 at 23:50
Hundreds is not a lot. Not for the DI container at least.
– Henk Holterman
Nov 23 '18 at 23:50
1
1
However when I have hundreds of these it becomes on BIG mess - It shouldn't be a mess, because you will have one function where you execute hundreds of simple, clear and understandable lines of code.
– Fabio
Nov 24 '18 at 8:06
However when I have hundreds of these it becomes on BIG mess - It shouldn't be a mess, because you will have one function where you execute hundreds of simple, clear and understandable lines of code.
– Fabio
Nov 24 '18 at 8:06
|
show 4 more comments
2 Answers
2
active
oldest
votes
If you really have hundreds of them, you may want to replace the default container with for example Autofac. These type of frameworks supports modules or kind of "subcontainers".
A module is a small class that can be used to bundle up a set of related components behind a ‘facade’ to simplify configuration and deployment.
Replace DI
Autofac modules
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
1
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
1
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
add a comment |
You can have each logical group of services (assemly) export its own RegisterServices method. It is the responsibility of that assembly to select lifetime and scope anyway.
For cosmetics, make it an AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace.
See AddMvc() for an example. Look it up (F12) and notice the difference between the assembly and the namespace it is in.
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450771%2fkeeping-net-dependency-injection-in-order%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you really have hundreds of them, you may want to replace the default container with for example Autofac. These type of frameworks supports modules or kind of "subcontainers".
A module is a small class that can be used to bundle up a set of related components behind a ‘facade’ to simplify configuration and deployment.
Replace DI
Autofac modules
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
1
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
1
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
add a comment |
If you really have hundreds of them, you may want to replace the default container with for example Autofac. These type of frameworks supports modules or kind of "subcontainers".
A module is a small class that can be used to bundle up a set of related components behind a ‘facade’ to simplify configuration and deployment.
Replace DI
Autofac modules
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
1
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
1
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
add a comment |
If you really have hundreds of them, you may want to replace the default container with for example Autofac. These type of frameworks supports modules or kind of "subcontainers".
A module is a small class that can be used to bundle up a set of related components behind a ‘facade’ to simplify configuration and deployment.
Replace DI
Autofac modules
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
If you really have hundreds of them, you may want to replace the default container with for example Autofac. These type of frameworks supports modules or kind of "subcontainers".
A module is a small class that can be used to bundle up a set of related components behind a ‘facade’ to simplify configuration and deployment.
Replace DI
Autofac modules
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
answered Nov 23 '18 at 17:38
RichyP7RichyP7
315
315
1
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
1
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
add a comment |
1
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
1
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
1
1
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
Do you have any idea if the process of migrating to Autofac can happen easily or I should have started using it from the begging?
– Kaloyan Manev
Nov 23 '18 at 17:42
1
1
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
Maybe take a look at this.stackoverflow.com/questions/42809618/… I used autofac in wcf projects, but in .net core I haven´t had problems with the default container.
– RichyP7
Nov 23 '18 at 17:46
add a comment |
You can have each logical group of services (assemly) export its own RegisterServices method. It is the responsibility of that assembly to select lifetime and scope anyway.
For cosmetics, make it an AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace.
See AddMvc() for an example. Look it up (F12) and notice the difference between the assembly and the namespace it is in.
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
add a comment |
You can have each logical group of services (assemly) export its own RegisterServices method. It is the responsibility of that assembly to select lifetime and scope anyway.
For cosmetics, make it an AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace.
See AddMvc() for an example. Look it up (F12) and notice the difference between the assembly and the namespace it is in.
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
add a comment |
You can have each logical group of services (assemly) export its own RegisterServices method. It is the responsibility of that assembly to select lifetime and scope anyway.
For cosmetics, make it an AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace.
See AddMvc() for an example. Look it up (F12) and notice the difference between the assembly and the namespace it is in.
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
You can have each logical group of services (assemly) export its own RegisterServices method. It is the responsibility of that assembly to select lifetime and scope anyway.
For cosmetics, make it an AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace.
See AddMvc() for an example. Look it up (F12) and notice the difference between the assembly and the namespace it is in.
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
answered Nov 23 '18 at 23:55
Henk HoltermanHenk Holterman
211k22234410
211k22234410
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450771%2fkeeping-net-dependency-injection-in-order%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I’m very much interested why you have hundreds of them. That seems like a gigantic project, or a problem in design.
– Sami Kuhmonen
Nov 23 '18 at 17:23
1
Assuming you do need them and can't break the project apart, you can use reflection to find the classes to register based on their names, attributes or interfaces they implement. That's how more advanced IoC containers like Autofac work. You can integrate Autofac with ASP.NET Core or you can implement a similar technique
– Panagiotis Kanavos
Nov 23 '18 at 17:34
2
You can have each group of services (assemly) export its own RegisterServices method. For fancy cosmetics, make it an
AddMyStuff()extension method in theMicrosoft.Extensions.DependencyInjectionnamespace. SeeAddMvc()for an example.– Henk Holterman
Nov 23 '18 at 18:11
1
Hundreds is not a lot. Not for the DI container at least.
– Henk Holterman
Nov 23 '18 at 23:50
1
However when I have hundreds of these it becomes on BIG mess - It shouldn't be a mess, because you will have one function where you execute hundreds of simple, clear and understandable lines of code.
– Fabio
Nov 24 '18 at 8:06