0

Following the guidelines I read in: https://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container

I want to try and avoid using a service locator. But on the other hand, I don't register all the types in the startup.cs file. I don't think this is right that all these internal types are referenced in the main startup.cs

I currently have a factory class that has a collection of builder classes. Each builder class is in charge of creating a specific object. I don't want to create all these builder classes in advance as I might not need to use them and creating them is a bit heavy. I saw an example of how to achieve this in the link above. However the startup.cs class needs to know all these builders. I don't think this is appropriate, I'd rather have the factory class be the only one that is exposed to them. I was trying to understand if there is some kind of func/action method that I can inject from the startup.cs file into my factory class. This func/action will be in charge of creating/registering the builders and then I can activate this func/action within the class factory. I'd like this func/action to receive the interface/class/maybe name of the builder but using generics isn't working. I searched a lot and didn't find any solution so I assume this is not possible. Seems I have 2 options: 1. Use service locator. This way only the factory class will know the builders. However if in the future, if I want to change the DI I need to "touch" the factory class (I'm contaminating the factory class). Wanted all the DI code to be located only in the startup.cs class. 2. Register the builders in the startup.cs but now the startup.cs is aware of the builders. This kinda couples the code, not really single role of responsibility

It would have been great to inject the factory class a func/action from the startup.cs that would do the registration but the factory class itself activates it. Is this possible?

Vijayanath Viswanathan
  • 8,027
  • 3
  • 25
  • 43
TaLz
  • 72
  • 1
  • 7
  • There is nothing wrong with registering types in a single class. If you want to, you can move it to a config file. – FCin Oct 18 '17 at 09:47
  • Well, I don't like config files and in general try to avoid them. As registering all the types in startup.cs - doesn't this seem not so healthy. If we ever want to change a builder, we need to "leave" the factory/builder area and jump over to startup.cs and start removing/adding registration. I think it is a good place to register general components such as Logger/Configuration/etc. but not load all my types in one place. – TaLz Oct 18 '17 at 10:27
  • You dont change old dependency every hour, so I dont understand what the problem is to just go to a single file and change a single line of code. – FCin Oct 18 '17 at 11:07
  • strongly related: https://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application – Steven Oct 18 '17 at 11:07

1 Answers1

3

I want to try and avoid using a service locator

Great, because the Service Locator is an anti-patttern.

don't register all the types in the startup.cs file.

You should do your registrations in one single 'area' of your application: the start-up path. This area is commonly referred to as the Composition Root (the place where object graphs are composed).

I don't think this is right that all these internal types are referenced in the main startup.cs

No matter how you design it, the startup assembly is the most volatile part of the system and it always depends on all other assemblies in the application. Either directly or transitively (through another referenced assembly). The whole idea of Dependency Injection is to minimize the coupling between components and the way to do this is to centralize coupling by moving it to the Composition Root. By making types internal however, you are decentralizing object composition and that limits your flexability. For instance, it becomes harder to apply decorators or interceptors for those registered types and control them globally. Read this question and its two top voted answers for more information.

I don't register all the types

The concern of having a Composition Root that is too big is not a valid one. One could easily split out the Composition Root into multiple smaller functions or classes that all reside in the startup assembly. On top of that, if you read this, you'll understand that registering all types explicitly (a.k.a. "Explicit Register") is typically pointless. In that case you're probably better off in using DI without a Container (a.k.a. Pure DI). Composition Roots where all types are registered explicitly are not very maintainable. One of the areas a DI Container becomes powerful is through its batch-registration facilities. They use reflection to load and register a complete set of types in a few lines of code. The addition of new types won't cause your Composition Root to change giving you the highest amount of maintainability.

I don't want to create all these builder classes in advance as I might not need to use them and creating them is a bit heavy

Creation of instances should never be heavy. Your injection constructors should be simple and composing object graphs should be reliable. This makes building even the biggest object graphs extremely fast. Factories should be reduced to an absolute minimum.

TLDR;

  • Register or compose your object graphs solely in the Composition Root.
  • Refrain from using the Service Locator anti-pattern; Whole applications can (and should) be built purely with Constructor Injection.
  • Make injection constructors simple and prevent them from doing anything else than storing their incoming dependencies.
  • Refrain from using factories to compose services, they are not needed in most cases.
Steven
  • 166,672
  • 24
  • 332
  • 435
  • I do not think that "service locator is a anti-pattern". It is a very useful pattern to solve dynamic resolution inside some very rare points of your source code. Abusing any pattern is smelly - but that's not the patterns fault. – quadroid Oct 18 '17 at 12:06
  • @Console: Service Locator _is_ an anti-pattern, there is little discussion about that nowadays. But you might be confused over what is and what isn't a Service Locator. Here's a [good article](http://blog.ploeh.dk/2011/08/25/ServiceLocatorrolesvs.mechanics/) that explains that not every use of a `Resolve` method is a service locator, it depends on its role in the system. – Steven Oct 18 '17 at 12:09
  • Well if you put it that way - it matches what you said ;). I need another name for the `architectural code that uses the mechanism of service location` stuff than – quadroid Oct 18 '17 at 12:17
  • As long as it is used _inside_ the Composition Root, it's not an implementation of the Service Locator. If services are queried _outside_ the Composition Root, it _is_ an implementation of the Service Locator anti-pattern. – Steven Oct 18 '17 at 12:18