3 ms·
If I understand the argument correctly, this is a problem that some DI frameworks already address. And in others, there's an easy workaround. Say you have a cl
by codeflo 11y ago
If I understand the argument correctly, this is a problem that some DI frameworks already address. And in others, there's an easy workaround.
Say you have a class CustomerHandler (stupid example, pseudo-C#) with a constructor like this:
public CustomerHandler(Guid customerId, ILogger logger, ISomeExtraDependency whatever) { ... }
Now, let's say another class needs to create CustomerHandlers for specific customers, but doesn't want to care how they are created. Autofac, the .NET DI framework I'm most familiar with, let's you inject factory delegates:
public RequestProcessor(Func<Guid, CustomerHandler) customerHandlerFactory) { ... }
(Every type not mentioned in the Func<> is auto-injected.) This is very convenient because you can change the dependencies of CustomerHandler without messing up the rest of the code.
Of course, even in the absence of such an auto-factory feature, you can still create a dedicated CustomerHandlerFactory class and inject that. That's not quite as convenient, but it's still a lot better to have only one extra place that has to know CustomerHandler's dependencies than having them all over your codebase.