Suppose I have an interface registered by 3pty library to the default container
// 3pty lib
public interface IFoo {
SayHello();
SayBye();
}
internal sealed class FooInternal : IFoo { ... }
public static WithFoo(this IServiceCollection serviceCollection) {
serviceCollection.AddScoped<IFoo, FooInternal>();
}
And I do want to overwrite the SayBye() method. I've created a class
class FooProxy : IFoo {
private readonly IFoo baseFoo;
public FooProxy(IFoo baseFoo) {
this.baseFoo = baseFoo;
}
public void SayHello() { baseFoo.SayHello(); }
public void SayBye() { ... }
}
Now the problem I'm facing is how to hook it up to dependency injection.
I've tried:
// leads to infinite recursion death
services.AddScoped<IFoo>((sp) => new FooProxy(sp.GetRequiredService<IFoo>()));
And also:
public class FooProxy : IFoo {
private readonly Func<IFoo> baseFoo;
SayHello() { baseFoo().SayHello(); }
}
// leads to object disposed error
services.AddScoped<IFoo>((sp) => new FooProxy(() => sp.GetRequiredService<IFoo>()));
This is something you can achieve using Decorator Pattern.
For this there is one library.
https://github.com/khellang/Scrutor
service.AddScoped<IFoo,FooConcrete>(); // This I believe register by Third Party
service.Decorate<IFoo,FooProxy>(); // This is you will add.
Another way which is bit not good.
public interface IFooProxy: IFoo
{
}
public class FooProxy : IFooProxy
{
public FooProxy(IFoo foo)
{
}
}
// Configure Sevices
services.AddScoped<IFooProxy,FooProxy>();
I'm trying to resolve an interface that I registered in Autofac but it seems to be not working. There is
nullreferenceexception.
Class where I register the inferface :
public void RegisterAutofac(HttpConfiguration config)
{
var builder = new ContainerBuilder();
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
(...)
builder.RegisterType<ApiFileTester>().As<IApiFlTester>().InstancePerRequest();
var container = builder.Build();
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
}
Then I want to use it in a class :
public class ApiFileSendingController : ApiClientBase
{
private readonly IApiFlTester _apiFileTester;
public ApiFileSendingController(DTO dto, IApiFlTester tester) : base(dto)
{
_tester = tester;
}
public void Send(List<AftInvFileDTO> filesToSendRetry = null)
{
_apiFileTester.RegisterTestingMethods();
}
}
Then in some other class:
DTO dto = new DTO(); //some configuration here
ApiFileSendingController sender = new ApiFileSendingController(dto, null);
sender.Send();
There is a problem here because my interface is null. I've tried to pass it like this:
ApiFileSendingController sender = new ApiFileSendingController(dto,
null);
but it's null and it's completely reasonable (I am passing the null).
IS it possible to configure optional parameter or something? I'd like to have this interface resolved automatically by autofac, not manually.
I don't seem to have a problem resolving your class. Technically it's impossible to really answer your question since the code won't even compile and it appears you have a ton of missing autofac registrations.
Working Example.
// #nuget: Autofac
using System;
using Autofac;
public class Program
{
private static IContainer _container;
public static void Main()
{
RegisterAutofac();
using (var httpRequestScope = _container.BeginLifetimeScope("AutofacWebRequest"))
{
var apiController = httpRequestScope.Resolve<ApiFileSendingController>();
Console.WriteLine(apiController._apiFileTester);
}
}
public static void RegisterAutofac()
{
var builder = new ContainerBuilder();
//builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterType<ApiFileTester>().As<IApiFlTester>().InstancePerLifetimeScope();
builder.RegisterType<ApiFileSendingController>().AsSelf();
builder.RegisterType<DTO>().AsSelf();
_container = builder.Build();
}
public class ApiFileSendingController : ApiClientBase
{
public readonly IApiFlTester _apiFileTester;
public ApiFileSendingController(DTO dto, IApiFlTester tester): base (dto)
{
_apiFileTester = tester;
}
}
public interface IApiFlTester { }
public class ApiFileTester : IApiFlTester { }
public class ApiClientBase
{
public ApiClientBase(DTO dto)
{
}
}
public class DTO { }
}
You have misconception at Autofac DI, most of the DI frameworks are good at creating instances for you, via constructor injection and property injection you will get the instance with their dependencies automatically wired up.
Your constructor contains DTO instance which you will provide during runtime, Autofac will not resolve that since you had not declare it to the DI container during ConfigureServices cycle.
You might need to giving up using Autofac in this case to get the freedom of creating controller instance at your own code, you will need to get the concrete class instance from Reflection instead. The abstraction / implementation isolation is still there via this approach.
public class ApiFileSendingController : ApiClientBase
{
private readonly IApiFlTester _apiFileTester;
public ApiFileSendingController(DTO dto, IApiFlTester tester) : base(dto)
{
if (tester is null)
_tester = GetApiTesterViaReflection();
else
_tester = tester;
}
public ApiFileSendingController(DTO dto) : base(dto)
{
_apiFileTester = GetApiTesterViaReflection();
}
public void Send(List<AftInvFileDTO> filesToSendRetry = null)
{
_apiFileTester.RegisterTestingMethods();
}
private IApiFlTester GetApiTesterViaReflection()
{
Type type = typeof(IApiFlTester).Assembly.GetTypes().Where(t => t.GetInterfaces().Contains(typeof(IApiFlTester))).FirstOrDefault();
return Activator.CreateInstance(type) as IApiFlTester;
}
}
I need to be able to pass a connection string into some of my service implementations. I am doing this in the constructor. The connection string is configurable by user will be added the ClaimsPrincipal as a Claim.
All fine so far.
Unfortunately, I also want to be able to use the dependency injection features in ASP.NET Core to the fullest and resolve the service implementation though DI.
I have a POC implmentation:
public interface IRootService
{
INestedService NestedService { get; set; }
void DoSomething();
}
public class RootService : IRootService
{
public INestedService NestedService { get; set; }
public RootService(INestedService nestedService)
{
NestedService = nestedService;
}
public void DoSomething()
{
// implement
}
}
public interface INestedService
{
string ConnectionString { get; set; }
void DoSomethingElse();
}
public class NestedService : INestedService
{
public string ConnectionString { get; set; }
public NestedService(string connectionString)
{
ConnectionString = connectionString;
}
public void DoSomethingElse()
{
// implement
}
}
These services have been registered during startup and INestedService has been added the constructor of a controller.
public HomeController(INestedService nestedService)
{
NestedService = nestedService;
}
As expected, I get the error Unable to resolve service for type 'System.String' while attempting to activate 'Test.Dependency.Services.NestedService'.
What are my options here?
To pass a runtime parameter not known at the start of the application, you have to use the factory pattern. You have two options here:
factory class (similar to how IHttpClientFactory is implemented)
public class RootService : IRootService
{
public RootService(INestedService nested, IOtherService other)
{
// ...
}
}
public class RootServiceFactory : IRootServiceFactory
{
// in case you need other dependencies, that can be resolved by DI
private readonly IServiceProvider services;
public RootServiceFactory(IServiceProvider services)
{
this.services = services;
}
public IRootService CreateInstance(string connectionString)
{
// instantiate service that needs runtime parameter
var nestedService = new NestedService(connectionString);
// note that in this example, RootService also has a dependency on
// IOtherService - ActivatorUtilities.CreateInstance will automagically
// resolve that dependency, and any others not explicitly provided, from
// the specified IServiceProvider
return ActivatorUtilities.CreateInstance<RootService>(services,
new object[] { nestedService, });
}
}
and inject IRootServiceFactory instead of your IRootService
IRootService rootService = rootServiceFactory.CreateInstance(connectionString);
factory method
services.AddTransient<Func<string,INestedService>>((provider) =>
{
return new Func<string,INestedService>(
(connectionString) => new NestedService(connectionString)
);
});
and inject the factory method into your service instead of INestedService
public class RootService : IRootService
{
public INestedService NestedService { get; set; }
public RootService(Func<string,INestedService> nestedServiceFactory)
{
NestedService = nestedServiceFactory("ConnectionStringHere");
}
public void DoSomething()
{
// implement
}
}
or resolve it per call
public class RootService : IRootService
{
public Func<string,INestedService> NestedServiceFactory { get; set; }
public RootService(Func<string,INestedService> nestedServiceFactory)
{
NestedServiceFactory = nestedServiceFactory;
}
public void DoSomething(string connectionString)
{
var nestedService = nestedServiceFactory(connectionString);
// implement
}
}
Simple configuration
public void ConfigureServices(IServiceCollection services)
{
// Choose Scope, Singleton or Transient method
services.AddSingleton<IRootService, RootService>();
services.AddSingleton<INestedService, NestedService>(serviceProvider=>
{
return new NestedService("someConnectionString");
});
}
With appSettings.json
If you decide to hide your connection string inside appSettings.json, e.g:
"Data": {
"ConnectionString": "someConnectionString"
}
Then provided that you've loaded your appSettings.json in the ConfigurationBuilder (usually located in the constructor of the Startup class), then your ConfigureServices would look like this:
public void ConfigureServices(IServiceCollection services)
{
// Choose Scope, Singleton or Transient method
services.AddSingleton<IRootService, RootService>();
services.AddSingleton<INestedService, NestedService>(serviceProvider=>
{
var connectionString = Configuration["Data:ConnectionString"];
return new NestedService(connectionString);
});
}
With extension methods
namespace Microsoft.Extensions.DependencyInjection
{
public static class RootServiceExtensions //you can pick a better name
{
//again pick a better name
public static IServiceCollection AddRootServices(this IServiceCollection services, string connectionString)
{
// Choose Scope, Singleton or Transient method
services.AddSingleton<IRootService, RootService>();
services.AddSingleton<INestedService, NestedService>(_ =>
new NestedService(connectionString));
}
}
}
Then your ConfigureServices method would look like this
public void ConfigureServices(IServiceCollection services)
{
var connectionString = Configuration["Data:ConnectionString"];
services.AddRootServices(connectionString);
}
With options builder
Should you need more parameters, you can go a step further and create an options class which you pass to RootService's constructor. If it becomes complex, you can use the Builder pattern.
I devised this little pattern to help me resolve objects that require runtime parameters ,but also have dependencies which the DI container is able to resolve - I implemented this using the MS DI Container for a WPF App.
I already had a Service Locator (yes I know its a code smell - but I attempt to resolve that by the end of the example) that I used in specific scenarios to get access to objects in the DIC:
public interface IServiceFactory
{
T Get<T>();
}
Its implementation takes a func<> in the constructor to decouple the fact it relies on MS DI.
public class ServiceFactory : IServiceFactory
{
private readonly Func<Type, object> factory;
public ServiceFactory(Func<Type, object> factory)
{
this.factory = factory;
}
// Get an object of type T where T is usually an interface
public T Get<T>()
{
return (T)factory(typeof(T));
}
}
This was created in the composition root like so:
services.AddSingleton<IServiceFactory>(provider => new ServiceFactory(provider.GetService));
This pattern was extended to not only 'Get' objects of type T, but 'Create' objects of type T with parameters P:
public interface IServiceFactory
{
T Get<T>();
T Create<T>(params object[] p);
}
The implementation took another func<> to decouple the creation mechanism:
public class ServiceFactory : IServiceFactory
{
private readonly Func<Type, object> factory;
private readonly Func<Type, object[], object> creator;
public ServiceFactory(Func<Type, object> factory, Func<Type, object[], object> creator)
{
this.factory = factory;
this.creator = creator;
}
// Get an object of type T where T is usually an interface
public T Get<T>()
{
return (T)factory(typeof(T));
}
// Create (an obviously transient) object of type T, with runtime parameters 'p'
public T Create<T>(params object[] p)
{
IService<T> lookup = Get<IService<T>>();
return (T)creator(lookup.Type(), p);
}
}
The creation mechanism for the MS DI container is in the ActivatorUtilities extensions, here's the updated composition root:
services.AddSingleton<IServiceFactory>(
provider => new ServiceFactory(
provider.GetService,
(T, P) => ActivatorUtilities.CreateInstance(provider, T, P)));
Now that we can create objects the problem becomes we have no way of determining the type of object we need without the DI container actually creating an object of that type, which is where the IService interface comes in:
public interface IService<I>
{
// Returns mapped type for this I
Type Type();
}
This is used to determine what type we are trying to create, without actually creating the type, its implementation is:
public class Service<I, T> : IService<I>
{
public Type Type()
{
return typeof(T);
}
}
So to pull it all together, in your composition root you can have objects that don't have runtime parameters which can be resolved by 'Get' and ones which do resolved by 'Create' e.g.:
services.AddSingleton<ICategorySelectionVM, CategorySelectionVM>();
services.AddSingleton<IService<ISubCategorySelectionVM>, Service<ISubCategorySelectionVM, SubCategorySelectionVM>>();
services.AddSingleton<ILogger, Logger>();
The CategorySelectionVM has only dependencies that can be resolved via the DIC:
public CategorySelectionVM(ILogger logger) // constructor
And this can be created by anyone with a dependency on the service factory like:
public MainWindowVM(IServiceFactory serviceFactory) // constructor
{
}
private void OnHomeEvent()
{
CurrentView = serviceFactory.Get<ICategorySelectionVM>();
}
Where as the SubCategorySelectionVM has both dependencies that the DIC can resolve, and dependencies only known at runtime:
public SubCategorySelectionVM(ILogger logger, Category c) // constructor
And these can be created like so:
private void OnCategorySelectedEvent(Category category)
{
CurrentView = serviceFactory.Create<ISubCategorySelectionVM>(category);
}
Update : I just wanted to add a little enhancement which avoided using the service factory like a service locator, so I created a generic service factory which could only resolve objects of type B:
public interface IServiceFactory<B>
{
T Get<T>() where T : B;
T Create<T>(params object[] p) where T : B;
}
The implementation of this depends on the original service factory which could resolve objects of any type:
public class ServiceFactory<B> : IServiceFactory<B>
{
private readonly IServiceFactory serviceFactory;
public ServiceFactory(IServiceFactory serviceFactory)
{
this.serviceFactory = serviceFactory;
}
public T Get<T>() where T : B
{
return serviceFactory.Get<T>();
}
public T Create<T>(params object[] p) where T : B
{
return serviceFactory.Create<T>(p);
}
}
The composition root adds the original service factory for all the generic typed factories to depend on, and any of the typed factories:
services.AddSingleton<IServiceFactory>(provider => new ServiceFactory(provider.GetService, (T, P) => ActivatorUtilities.CreateInstance(provider, T, P)));
services.AddSingleton<IServiceFactory<BaseVM>, ServiceFactory<BaseVM>>();
Now our main view model can be restricted to creating only objects that derive from BaseVM:
public MainWindowVM(IServiceFactory<BaseVM> viewModelFactory)
{
this.viewModelFactory = viewModelFactory;
}
private void OnCategorySelectedEvent(Category category)
{
CurrentView = viewModelFactory.Create<SubCategorySelectionVM>(category);
}
private void OnHomeEvent()
{
CurrentView = viewModelFactory.Get<CategorySelectionVM>();
}
I know this is a bit old but thought i'd give my input since there is a easier way to do this in my opinion. This doesn't cover all the cases as shown in other posts. But this is a easy way of doing it.
public class MySingleton {
public MySingleton(string s, int i, bool b){
...
}
}
No lets create a service extention class to add easier and keep it neet
public static class ServiceCollectionExtentions
{
public static IServiceCollection RegisterSingleton(this IServiceCollection services, string s, int i, bool b) =>
services.AddSingleton(new MySingleton(s, i, b));
}
Now to call it from startup
services.RegisterSingleton("s", 1, true);
IMHO, follow the options pattern. Define a strong type to hold your connection string, then an IConfigureOptions<T> to configure it from your user claim.
public class ConnectionString {
public string Value { get; set; }
}
public class ConfigureConnection : IConfigureOptions<ConnectionString> {
private readonly IHttpContextAccessor accessor;
public ConfigureConnection (IHttpContextAccessor accessor) {
this.accessor = accessor;
}
public void Configure(ConnectionString config) {
config.Value = accessor.HttpContext.User ...
}
}
public class NestedService {
...
public NestedService(IOptions<ConnectionString> connection) {
ConnectionString = connection.Value.Value;
}
...
}
Further to #Tseng's extremely helpful answer, I found I could also adapt it to use delegates:
public delegate INestedService CreateNestedService(string connectionString);
services.AddTransient((provider) => new CreateNestedService(
(connectionString) => new NestedService(connectionString)
));
Implemented in RootService in the same way #Tseng suggested:
public class RootService : IRootService
{
public INestedService NestedService { get; set; }
public RootService(CreateNestedService createNestedService)
{
NestedService = createNestedService("ConnectionStringHere");
}
public void DoSomething()
{
// implement
}
}
I prefer this approach for cases where I need an instance of a factory in a class, as it means I can have a property of type CreateNestedService rather than Func<string, INestedService>.
I had a class before I introduced dependency inject that looked like this:
public class Widget
{
public Widget Create()
{
using (DataProvider dataProvider = new DataProvder())
{
dataProvider.AddInput("name", name);
dataProvider.AddInput("path", path);
dataProvider.AddInput("dateCreated", DateTime.UtcNow);
using (var reader = _dataProvider.ExecuteReader("usp_widget_create"))
{
reader.Read();
return new Widget(reader);
}
}
}
}
Then I introduced dependency inject using Ninject and my class now looks like this so I don't create a dependency to the DataProvider class.
public class Widget
{
IDataProvider _dataProvider;
public Widget(IDataProvider dataProvider)
{
_dataProvider = dataProvider;
}
public Widget Create()
{
_dataProvider.AddInput("name", name);
_dataProvider.AddInput("path", path);
_dataProvider.AddInput("dateCreated", DateTime.UtcNow);
using (var reader = _dataProvider.ExecuteReader("usp_widget_create"))
{
reader.Read();
return new Widget(reader);
}
}
}
The problem with the new class is that one, the DataProvider won't get disposed and two, the properties of the DataProvider won't be reset. So if I call Create from the same object twice it will duplicate the parameters and throw an exception. I know I can explicitly fix the second issue by clearing the parameters, but I feel like there must be a more universal approach and I am missing something.
How should this situation be resolved?
The pattern that very much you want to utilize is the Dependency Injection with Abstract Factory Pattern.
This factory pattern allows you dynamically create instances whenever you required. And it is a very common thing to do so.
Define a Factory that allows you to create Provide instances.
public interface IProviderFactory
{
T Create<T>();
}
The implementation can be simple as below.
public class ProviderFactory : IProviderFactory
{
private readonly IKernel _kernel;
public ProviderFactory(IKernel kernel)
{
_kernel = kernel;
}
public T Create<T>()
{
var instance = _kernel.Get<T>();
return instance;
}
}
Now change your Widget to accept the Factory instead of the IDataProvider
public class Widget
{
readonly IProviderFactory _factory;
public Widget(IProviderFactory factory)
{
_factory = factory;
}
public Widget Create()
{
var provider = _factory.Create<IDataProvider>();
provider.AddInput("name", "name");
provider.AddInput("path", "path");
provider.AddInput("dateCreated", DateTime.UtcNow);
//.....
}
}
Note that each invocation of Create() would resolve a new instance of the IDataProvider.
var provider = _factory.Create();
The Kernal Registration is something like below..
using (IKernel Kernel = new StandardKernel())
{
Kernel.Bind<IDataProvider>().To<DataProvider>();
Kernel.Bind<IProviderFactory>()
.To<ProviderFactory>().WithConstructorArgument(typeof(IKernel), Kernel);
var widget = Kernel.Get<Widget>();
widget.Create();
widget.Create();
}
Something along line should provide you the direction to a possible solution.
I have the following interface defined
IOne
ITwo
IThree
ICalcalculator
And have several implementations of them
ClassOne: IOne
ClassTwo: IOne
ClassThree : ITwo
ClassFour : ITwo
ClassFive: IThree
MyCalc : ICalculator
MyCalc requires classes 1-4, however 2 instances of ClassOne and ClassThree differentiated as initialization i.e.
public MyCalc(){
ClassOne first= new ClassOne("filePath1");
ClassOne second = new ClassOne("filePath2");
ClassThree third = new ClassThree ("filePath3");
ClassThree fourth = new ClassThree ("filePath4");
}
I am trying to use MEF to create construct MyCalc. In the above example, the filePathX will be in a configuration file. I have done the following thus far and it seems to work, however my feeling is that my current method and approach is not correct. Looking at this approach, I have bound myself with names (ValDatePrices & EDDatePrices) and it is no cleaner than my current approach(see above).
Is there a cleaner way to load several objects of the same type with different ctor arguments?
public class MyCalc: ICalculator
{
private CompositionContainer container;
public MyCalc()
{
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(typeof(MyCalc).Assembly));
container = new CompositionContainer(catalog);
try
{
this.container.ComposeExportedValue<ClassFive>(
new ClassFive((ConfigurationManager.AppSettings["SomePath"])));
this.container.ComposeExportedValue<ClassOne>(
"ValDatePrices"
, new ClassOne((ConfigurationManager.AppSettings["filePath1"])));
this.container.ComposeExportedValue<ClassOne>(
"EDDatePrices"
, new ClassOne((ConfigurationManager.AppSettings["filePath2"])));
this.container.ComposeParts(this);
}
catch (CompositionException compositionException)
{
Console.WriteLine(compositionException.ToString());
}
}
[Import("ValDatePrices")]
public ClassOne ValDatePrices;
[Import("EDDatePrices")]
public ClassOne EDDatePrices;
[Import]
public ClassFive SPointReader;
public void Calculate()
{
Console.WriteLine(SPointReader.Result);
Console.WriteLine(ValDatePrices.Result.Count);
Console.WriteLine(EDDatePrices.Result.Count);
Console.ReadKey();
}
}
Usage
class Program
{
static void Main(string[] args)
{
var p = new MyCalc();
p.Calculate();
}
}
}
Side question: where should the code in the MyCalc constructor be located?
Have you considered using a proper DI/IoC container? This can be easily achieved in a clean way using e.g. NInject or StructureMap.
Here is an example of how this can be implemented with NInject. Note that there are numerous ways of doing this, you should look at their tutorial to get NInject to suit you needs.
MyCalculator
public class MyCalculator : ICalculator
{
private IOne _oneFirst;
private IOne _oneSecond;
private ITwo _twoFirst;
private ITwo _twoSecond;
private IThree _three;
public MyCalculator([Named("Val")] IOne oneFirst, [Named("ED")] IOne oneSecond,
[Named("Val")] ITwo twoFirst, [Named("ED")] ITwo twoSecond, IThree three)
{
_oneFirst = oneFirst;
_oneSecond = oneSecond;
_twoFirst = twoFirst;
_twoSecond = twoSecond;
_three = three;
}
public void Calculate()
{
}
}
Kernel
public class CalculatorModule : NinjectModule
{
public override void Load()
{
Bind<IOne>().ToMethod(CreateOne).Named("Val");
Bind<IOne>().ToMethod(CreateTwo).Named("ED");
Bind<ITwo>().ToMethod(CreateThree).Named("Val");
Bind<ITwo>().ToMethod(CreateFour).Named("ED");
Bind<IThree>().To<ClassFive>();
Bind<ICalculator>().To<MyCalculator>();
}
private ITwo CreateFour(IContext arg)
{
return new ClassFour();
}
private ITwo CreateThree(IContext arg)
{
return new ClassThree();
}
private IOne CreateOne(IContext context)
{
return new ClassOne("filePath1");
}
private IOne CreateTwo(IContext arg)
{
return new ClassTwo("filePath2");
}
}
Note about kernel: The methods can be shortened to lambda functions if you like and the named attributes can be replaced by parameter names or custom attributes. See Contextual Binding
Usage
class Program
{
static void Main(string[] args)
{
StandardKernel kernel = new StandardKernel(new CalculatorModule());
var cal = kernel.Get<ICalculator>();
cal.Calculate();
}
}