Having Automapper use services constructed by a Autofac with WebApi - c#

I'm using WebAPI + Autofac + Automapper, with a repository for data access. I need to map a model to my domain entities, specifically, I need to convert an identity value to the actual entity. No big deal, right? I've done this in MVC with no problem. I will simplify what I am doing to expose the essentials.
public class EntityConverter<T> : ITypeConverter<int, T>
where T : Entity
{
public EntityConverter(IRepository<T> repository)
{
_repository = repository;
}
private readonly IRepository<T> _repository;
public T Convert(ResolutionContext context)
{
_repository.Get((int) context.SourceValue);
}
}
Repositories are registered with Autofac, and are managed as InstancePerApiRequest because of session/transaction management. So, I need to register my converter in that same scope:
builder.RegisterGeneric(typeof(EntityConverter<>))
.AsSelf()
.InstancePerApiRequest();
The Automapper config looks something like:
var container = builder.Build(); // build the Autofac container and do what you will
Mapper.Initialize(cfg => {
cfg.ConstructServicesUsing(container.Resolve); // nope nope nope
// configure mappings
cfg.CreateMap<int, TestEntity>().ConvertUsing<EntityConverter<TestEntity>>()
});
Mapper.AssertConfigurationIsValid();
So here's the part that sucks. I am to understand Automapper requires the ConstructServicesUsing guy to be set before you build your config. If you set it later, it won't be used. The example above won't work because container is the root scope. If I try and resolve EntityConverter<TestEntity>, Autofac will complain that the requested type is registered for a different scope, and the one you're in ain't it. Makes sense, I want the scope created by WebApi.
Let me pause a sec and cover one fact about WebApi dependency injection (I don't really think this is Autofac-specific). WebApi creates an IDependencyScope for the request, and stashes it in the HttpRequestMessage.Properties. I can't get it back again unless I have access to that same HttpRequestMessage instance. My AsInstancePerApiRequest scoping on IRepository and my converter thus rely on that IDependencyScope.
So, that's really the meat and potatoes of the problem, and I really frustrated with this difference from MVC. You can't do
cfg.ConstructServicesUsing(GlobalConfiguration.Configuration.DependencyResolver.GetService);
That's equivalent to using container.Resolve. I can't use
GlobalConfiguration.Configuration.DependencyResolver.BeginScope().GetService
because A) that creates a new scope next to the one I actually want B) doesn't really let me clean up the new scope I created. Using Service Locator is a new way to have the same problem; I can't get to the scope WebApi is using. If my converter and its dependencies were single instance or instance per dependency, it wouldn't be a problem, but they aren't, so it is, and changing that would create lots more problems for me.
Now, I can create AutoMapper config with Autofac and register it as a single instance. I can even create per-request IMappingEngine instances. But that doesn't do me any good if the service constructor always uses that single delegate you register at the beginning, which has no access to the current scope. If I could change that delegate per each mapping engine instance, I might be in business. But I can't.
So what can I do?

Another option, this time it's built-in, is to use the per-map options:
Mapper.Map<Source, Destination>(dest, opt => opt.ConstructServicesUsing(type => Request.GetDependencyScope().GetService(typeof(YourServiceTypeToConstruct))));
Don't bother with setting up the global IoC config in your mapping configuration.
Another option is to use your IoC tool to configure how to instantiate the MappingEngine:
public MappingEngine(
IConfigurationProvider configurationProvider,
IDictionary<TypePair, IObjectMapper> objectMapperCache,
Func<Type, object> serviceCtor)
The first one is just Mapper.Configuration, the second should probably be a singleton, and the third you can fill in with the current nested container's resolution. This would simplify from having to call the Map overload every time.

Update: Automapper was updated to support that feature. See #Jimmy Bogard 's answer
This solution could be not very nice, but it works. The solution relates to WebAPI 2, I'm not sure about previous versions.
In WebAPI 2 you can get current IDependencyScope from current HttpRequestMessage via GetDependencyScope() extension method. Current HttpRequestMessage is stored in the Items property of the current HttpContext. Knowing that your factory could look like:
Mapper.Initialize(cfg =>
{
cfg.ConstructServicesUsing(serviceTypeToConstruct =>
{
var httpRequestMessage = HttpContext.Current.Items["MS_HttpRequestMessage"] as HttpRequestMessage;
var currentDependencyScope = httpRequestMessage.GetDependencyScope();
return currentDependencyScope.GetService(serviceTypeToConstruct);
});
// configure mappings
// ...
});

This may or may not be suitable for you.. but here goes:
We recently did this.. for model binders in MVC. Our model binders (on GET requests) now use Ninject-managed Services to build models.
Basically, we inject a factory (using Ninject's Factories extension.. perhaps there is a similar one for Autofac) into an "AutomapperBootstrapper" class, which in turn creates Automapper mapping Profile's and adds them to Automapper. Somewhat like this:
Mapper.Initialize(cfg =>
{
cfg.AddProfile(_factory.CreateServiceViewModelMappingProfile());
// etc..
});
The mappings Profile's themselves use MapFrom(), which is evaluated each time a mapping occurs. Something like this:
Mapper.CreateMap<Service, ServiceViewModel>()
.ForMember(x => x.Regions,
opt =>
opt.MapFrom(x => getRegions()))
private IEnumerable<Region> getRegions() {
return _factory.CreateTheService().GetRegions();
}
Each time the model binder is fired up, Ninject still wires up all dependencies for the request and it all filters down.
(For those interested, this setup basically lets us do this: /Area/Controller/Action/12, and our controller action method is this:
[HttpGet]
public ActionResult Action(ServiceViewModel model) {
// ...
}
).

Related

How Can I Resolve Other Dependencies within Ninject .OnActivation?

I am using Ninject to set up bindings for a class which is an IObservable.
I have set up a rebind to ensure that the IObservable has it's IObserver subscribed as follows...
kernel.Rebind<IAddressRepository>().To<AddressRepository>().InRequestScope()
.OnActivation(repo => repo
.Subscribe(new SyncTrackerDataEventObserver<Address, AddressRepository>()));
This seems to work OK but it really isn't ideal. SyncTrackerDataEventObserver will, when it's more than a stub have dependencies of it's own. Then we end up with this...
kernel.Rebind<IAddressRepository>().To<AddressRepository>().InRequestScope()
.OnActivation(repo => repo
.Subscribe(new SyncTrackerDataEventObserver<Address, AddressRepository>(new SyncTrackerRepository(new SyncDataSource))));
Ouch!!
What I want to do is make use of the existing bindings at this point. I'd expect to be able to write something like this (but this is just made up..)
kernel.Rebind<IAddressRepository>().To<AddressRepository>().InRequestScope()
.OnActivation(repo => repo
.Subscribe(kernel.Resolve<ISyncTrackerDataEventObserver>()));
What is the correct way to achieve this without creating a hell of hard coded dependencies and breaking IoC paradigms?
This was quite straightforward when I figured out where to look. kernel.TryGet<> will get you the service type from the current bindings.
kernel.Rebind<IAddressRepository>().To<AddressRepository>().InBackgroundJobScope()
.OnActivation(repo => repo
.Subscribe(kernel.TryGet<SyncTrackerDataEventObserver<Address, AddressRepository>>()
?? throw new ObserverBindingException("Address")));
(where ObserverBindingException is a custom exception type I created just for this purpose).

How can I use the built in DI to resolve a Child View's model?

I'm attempting to resolve the dependencies of a child view when calling it from the parent with #Html.Partial() like so.
#inject IServiceProvider ServiceProvider
//...
<body>
#Html.RenderPartial("Layouts/Elements/_Header", ServiceProvider.GetRequiredService<_HeaderModel>())
</body>
//...
Problem is that the Model _HeaderModel isn't registered to the DI Container. So I get the error:
InvalidOperationException: No service for type 'Client_Portal.Pages.Layouts._HeaderModel' has been registered.
But wait, neither are any of my other models and framework resolves their dependencies just fine! How is ASP.NET Core handling this behind the scenes and how can I do this myself? Does it add new models as it finds them? Maybe I'm missing a simple method that lets the framework handle this instead?
You're actually trying to implement this in what's called the service locator anti-pattern. As in this is not something you should be doing. ASP.NET Core provides a way to render partials with a separate and distinct model and/or injected dependencies: it's called view components. The usage is pretty basic overall.
First, create a ViewComponents directory in your project and add a HeaderViewComponent.cs file to that. Inside that, add a class like:
public class HeaderViewComponent : ViewComponent
{
public async Task<IViewComponentResult> InvokeAsync()
{
var model = await GetModelAsync();
return View(model);
}
public Task<HeaderModel> GetModelAsync()
=> return Task.FromResult(new HeaderModel());
}
The only required method is InvokeAsync. View components are always async. However, since in this example, nothing is actually happening async (just newing up an instance HeaderModel, I added a convenience method, GetModelAsync that returns the model wrapped in a Task, so there's something to await. If you were actually doing something async, like querying a database to fetch your model, then there's no need to wrap that in a Task separately.
With that in place, add a new view to Views\Shared\Components\Header\Default.cshtml. By convention the directory is dictated by the class name of the view component, i.e. the view for HeaderViewComponent will be looked for in Components\Header. Add your existing partial view code here.
Finally, in your layout or wherever else you need to bring in this partial, simply do:
#await Component.InvokeAsync("Header")
Since view components are just classes, they can be injected like any other class, meaning you can easily access your context or any other registered service you might need, simply by adding a constructor param for it.

Autofac resolve dependant services by name

Is it possible to register a single service that has dependencies that can change depending on a setting?
For instance
A DBExecutor requries a different DBconnection object depending which geographical region it is running under.
I've tried something like
builder.RegisterType<DbConnection>().Named<IDbConnection>("US")
builder.RegisterType<DbConnection>().Named<IDbConnection>("AU")
builder.RegisterType<SqlExecutor>().As<IDbExecutor>();
and I'd like to resolve the service with something like
var au = container.ResolveNamed<IDbExecutor>("AU");
var us = container.ResolveNamed<IDbExecutor>("US");
However this doesn't work because the IDbExecutor itself hasn't been registered with a key, and if I try a normal Resolve it wont work as it cannot create the dependent services.
Basically I just want an instance of of IDbExecutor with a DBConnection based upon a certain parameter.
I'm trying to do this in a more general sense so I'm trying to avoid any specific code where I can.
The current generic code I have that doesn't use keyed services looks like
var job = (IJob) lifetimeScope.Resolve(bundle.JobDetail.JobType);
where JobType is a class Type and depending on if this is possible the final version would look something like
var job = (IJob) lifetimeScope.Resolve(bundle.JobDetail.JobType, bundle.JobDetail.JobDataMap["Region"]);
where bundle.JobDetail.JobDataMap["Region"] would return either "AU" or "US"
You won't be able to rig it to resolve a named IDbExecutor because you didn't register it as named. It's also probably not the best idea since it implies that IDbExecutor somehow "knows" about its dependencies, which it shouldn't - the implementation knows, but the interface/service doesn't - and shouldn't.
You can get something close to what you want by updating the SqlExecutor to use the IIndex<X,B> relationship in Autofac. Instead of taking just an IDbConnection in your constructor, take an IIndex<string,IDbConnection>.
When you need to get the connection, look it up from the indexed dictionary using the job type:
public class SqlExecutor
{
private IIndex<string, IDbConnection> _connections;
public SqlExecutor(IIndex<string, IDbConnection> connections)
{
this._connections = connections;
}
public void DoWork(string jobType)
{
var connection = this._connections[jobType];
// do something with the connection
}
}
Another way to do it would be to create a delegate factory for the SqlExecutor that takes in the job type and automatically picks the right named service. That's a bit more involved so check out the documentation for an example.

Structuremap 3 multiple decoration

I am trying to create a dependency graph in StructureMap 3 with a chain of decorators:
Each instance has a constructor with multiple arugments, but exactly one argument of an inner IGeocoder, e.g.
public SomeCachingGeocoder(IGeoCoder inner, IFoo somethingElse)
I am hooking them up like this:
For<OviGeoCoder>().Use<OviGeoCoder>();
For<SqlCachingGeocoder>().Use<SqlCachingGeocoder>().Ctor<IGeoCoder>().Is<OviGeoCoder>();
For<RedisCachingGeocoder>().Use<RedisCachingGeocoder>().Ctor<IGeoCoder>().Is<SqlCachingGeocoder>();
For<IGeoCoder>().Use<RedisCachingGeocoder>();
But I get
Bi-directional dependency relationship detected! Check the StructureMap stacktrace below:
1.) Instance of SOAM.Services.IGeoCoder (SOAM.Services.Geocoding.RedisCachingGeocoder)
2.) new RedisCachingGeocoder(Default of IDatabase, Default of IGeoCoder)
3.) SOAM.Services.Geocoding.RedisCachingGeocoder
4.) Instance of SOAM.Services.IGeoCoder (SOAM.Services.Geocoding.RedisCachingGeocoder)
5.) new HomeController(Default of IGeoCoder, Default of IAlertService)
6.) SOAM.Web.Controllers.HomeController
7.) Instance of SOAM.Web.Controllers.HomeController
8.) Container.GetInstance(SOAM.Web.Controllers.HomeController)
Any ideas how to solve this?
DecorateAllWith allows auto-wiring by default and allows stacking decorators in a quite easy way:
For<IGeoCoder>().Use<OviGeoCoder>();
For(typeof(IGeoCoder)).DecorateAllWith(typeof(SqlCachingGeocoder));
For(typeof(IGeoCoder)).DecorateAllWith(typeof(RedisCachingGeocoder));
If for some reason you cannot use DecorateAllWith() then this should work:
var container = new Container(
c =>
{
c.For<IFoo>().Use<Foo>();
c.For<IGeoCoder>().Add<OviGeoCoder>().Named("default");
c.For<IGeoCoder>()
.Add<SqlCachingGeocoder>()
.Ctor<IGeoCoder>()
.Is(ctx => ctx.GetInstance<IGeoCoder>("default"))
.Named("SqlCaching");
c.For<IGeoCoder>()
.Use<RedisCachingGeocoder>()
.Ctor<IGeoCoder>()
.Is(ctx => ctx.GetInstance<IGeoCoder>("SqlCaching"));
});
Wanna find what's the difference when using Use vs Add? Take a look here

Ninject: How to bind ToMethod

i want to config my bindings.
Bind<DbContext>().To<HangTagVerwaltungContext>();
Bind<IUnitOfWork>()
.ToConstructor(
x => new UnitOfWork(true, true, x.Inject<DbContext>()));
// Managers
Bind<ITagManager>().To<TagManager>();
// ViewModels
Bind<TagEditViewModel>().ToMethod(
context =>
{
IUnitOfWork unitOfWork = context.Kernel.Get<IUnitOfWork>();
ITagManager tagManager =
context.Kernel.Get<ITagManager>(
new Parameter(#"unitOfWork", unitOfWork, false));
return new TagEditViewModel(tagManager,
context.Kernel.Get<INavigationService>(), unitOfWork);
});
My Problem is, that everytime he is creating a new UnitOfWork for the TagManager and not use the Parameter i give him in the ToMethod method. What do i wrong?
Thx for the Help.
Dennis
I think you should be using ConstructorArgument instead of Parameter. The parameter name will have to match that of the constructor.
However, why are you doing this so complicated? (DI is about making things easier for you, not more complicated.) Is it because you need the same IUnitOfWork instance for tagManager and TagEditViewModel?
If that's the case, there's other ways to achieve this. You should look into scopes. They are used to make some part of the object tree use the same instance.
For the scenario you showed you might want to try .InCallScope(), but generally for IUnitOfWork there's other things which work better in the whole application, like .InRequestScope() for web projects or some other custom scope. There's other stackoverflow questions already covering this.

Categories