How would you pass parameters to a resolver to create an object?
I have a UoW object which I want to pass into a data service objects, I want to be able to ensure that the data service objects created in a particular sequence are created using the one UoW object
for example
using (var context = Resolver.GetService<IUoW>())
{
var dataService1 = Resolver.GetService<IDataService1>();
var dataService2 = Resolver.GetService<IDataService2>();
// do some stuff
context.Commit();
}
Option 1, pass IUoW into the Resolver.GetService call
- there is no knowledge of the constructors for IDataServiceX implementations
Option 2, add a property to IDataServiceX for IUoW
- not setting it would be easily done, how would a programmer know this property was required to be set
I've previously implemented a Unit of Work (UoW) and Repository pattern over Entity Framework.
In reality the UoW abstracted the EF context, and the repositories abstracted the entity sets.
In my implementation of the Repositories were properties of the UoW, meaning it was not the IoC container that managed the life-cycle of the repositories, that was the responsibility of the UoW.
In your situation the repositories are named services, but maybe the same applies. Can the IUoW interface have two (or more) properties for all the services that exist within the specific unit of work?
Related
I have a base abstract context which has a couple hundred shared objects, and then 2 "implementation" contexts which both inherit from the base and are designed to be used by different tenants in a .net core application. A tenant object is injected into the constructor for OnConfiguring to pick up which connection string to use.
public abstract class BaseContext : DbContext
{
protected readonly AppTenant Tenant;
protected BaseContext (AppTenant tenant)
{
Tenant = tenant;
}
}
public TenantOneContext : BaseContext
{
public TenantOneContext(AppTenant tenant)
: base(tenant)
{
}
}
In startup.cs, I register the DbContexts like this:
services.AddDbContext<TenantOneContext>();
services.AddDbContext<TenantTwoContext>();
Then using the autofac container and th Multitenant package, I register tenant specific contexts like this:
IContainer container = builder.Build();
MultitenantContainer mtc = new MultitenantContainer(container.Resolve<ITenantIdentificationStrategy>(), container);
mtc.ConfigureTenant("1", config =>
{
config.RegisterType<TenantOneContext>().AsSelf().As<BaseContext>();
});
mtc.ConfigureTenant("2", config =>
{
config.RegisterType<TenantTwoContext>().AsSelf().As<BaseContext>();
});
Startup.ApplicationContainer = mtc;
return new AutofacServiceProvider(mtc);
My service layers are designed around the BaseContext being injected for reuse where possible, and then services which require specific functionality use the TenantContexts.
public BusinessService
{
private readonly BaseContext _baseContext;
public BusinessService(BaseContext context)
{
_baseContext = context;
}
}
In the above service at runtime, I get an exception "No constructors on type 'BaseContext' can be found with the constructor finder 'Autofac.Core.Activators.Reflection.DefaultConstructorFinder'". I'm not sure why this is broken....the AppTenant is definitely created as I can inject it other places successfully. I can make it work if I add an extra registration:
builder.RegisterType<TenantOneContext>().AsSelf().As<BaseContext>();
I don't understand why the above registration is required for the tenant container registrations to work. This seems broken to me; in structuremap (Saaskit) I was able to do this without adding an extra registration, and I assumed using the built in AddDbContext registrations would take care of creating a default registration for the containers to overwrite. Am I missing something here or is this possibly a bug in the multitenat functionality of autofac?
UPDATE:
Here is fully runable repo of the question: https://github.com/danjohnso/testapp
Why is line 66 of Startup.cs needed if I have lines 53/54 and lines 82-90?
As I expected your problem has nothing to do with multitenancy as such. You've implemented it almost entirely correctly, and you're right, you do not need that additional registration, and, btw, these two (below) too because you register them in tenant's scopes a bit later:
services.AddDbContext<TenantOneContext>();
services.AddDbContext<TenantTwoContext>();
So, you've made only one very small but very important mistake in TenantIdentitifcationStrategy implementation. Let's walk through how you create container - this is mainly for other people who may run into this problem as well. I'll mention only relevant parts.
First, TenantIdentitifcationStrategy gets registered in a container along with other stuff. Since there's no explicit specification of lifetime scope it is registered as InstancePerDependency() by default - but that does not really matter as you'll see. Next, "standard" IContainer gets created by autofac's buider.Build(). Next step in this process is to create MultitenantContainer, which takes an instance of ITenantIdentitifcationStrategy. This means that MultitenantContainer and its captive dependency - ITenantIdentitifcationStrategy - will be singletons regardless of how ITenantIdentitifcationStrategy is registered in container. In your case it gets resolved from that standard "root" container in order to manage its dependencies - well, this is what autofac is for anyways. Everything is fine with this approach in general, but this is where your problem actually begins. When autofac resolves this instance it does exactly what it is expected to do - injects all the dependencies into TenantIdentitifcationStrategy's constructor including IHttpContextAccessor. So, right there in the constructor you grab an instance of IHttpContext from that context accessor and store it for using in tenant resolution process - and this is a fatal mistake: there's no http request at this time, and since TenantIdentitifcationStrategy is a singleton it means that there will not ever be one for it! So, it gets null request context for the whole application lifespan. This effectively means that TenantIdentitifcationStrategy will not be able to resolve tenant identifier based on http requests - because it does not actually analyze them. Consequently, MultitenantContainer will not be able to resolve any tenant-specific services.
Now when the problem is clear, its solution is obvious and trivial - just move fetching of request context context = _httpContextAccessor.HttpContext to TryIdentifyTenant() method. It gets called in the proper context and will be able to access request context and analyze it.
PS. This digging has been highly educational for me since I had absolutely no idea about autofac's multi-tenant concept, so thank you very much for such an interesting question! :)
PPS. And one more thing: this question is just a perfect example of how important well prepared example is. You provided very good example. Without it no one would be able to figure out what the problem is since the most important part of it was not presented in the question - and sometimes you just don't know where this part actually is...
Let's say I've extended identity framework dbContext to build my own, and I've our authenticated controller who get injected with the dbContext and fetch an entity related with the current ApplicationUser, entity framework will relate the two entities leading to a server error because of circular references.
We don't want to serialize circular references.
So we create a new dbContext in the method who istantiate a new dbcontext and query the unrelated entities, this will work. But this is not testable, we don't want our controller to strictly depends on the dbContext, we want it to be injected.
So we add a second parameter, in the constructor, unfortunately this will make the system inject the same dbContext twice, not so useful.
We tried to create a class fakeDbContext who inherit from dbContext and add it services and use it, but now we got two dbcontext, who can potentially generate migrations and configurations and errors...
Which is the right way of doing this in the new MVC6 ?
Edit...
I found out that if my controller require an IEnumerable<dbContext> i get all the object registered as service of that type, so just doubling the part in startup.cs where we add the dbContext in the service registration area i get two of them...
The drawback here is that i don't know wich one is the virgin one, it looks like it goes in order of registration, but i have no clue, if this will change.
Edit 2 ...
I've created a TransientDbService class who have just a factory method taking the IserviceProvider, it use it to get the options to construct the dbContext, and then expose it. I've registered it as transient, then in the controller i require this service type.
the drawback here is if i'll ever need a third dbContext i should write more code, more code means errors and maintaning it.
Edit 3 ...
Not having two dbContext at all. The following setting allow me to have no relationships valorized.
Database.ChangeTracker.QueryTrackingBehavior = Microsoft.Data.Entity.QueryTrackingBehavior.NoTracking;
The drawback here is that i can't use my model graph, making everything more complex...
Edit 4 ...
https://github.com/aspnet/DependencyInjection/issues/352
You are right to think that no tracking queries will help in some cases, but other times you'll need to have more than one instance of the DbContext created.
You normally use the AddDbContext<TContext>() method in startup to make sure an instance of your context type is created per request and the right DbContextOptions and service provider get set on it. When you need to deviate from this pattern you have a few options, e.g.:
Include a constructor in your derived DbContext class that takes an IServiceProvider and passes it to the base constructor. Make sure your controller takes IServiceProvider. Once you do this you should be able to create DbContext manually with something like this:
using(var context1 = new MyDbContext(serviceProvider),
var context2 = new MyDbContext(serviceProvider))
{ ...
To avoid having to change the constructor signatures on your derived DbContext type you can take advantage of the DbContextActivator class (it is our Internal namespace), e.g.:
using(var context1 = DbContextActivator.CreateInstance<MyDbContext>(serviceProvider),
var context2 = DbContextActivator.CreateInstance<MyDbContext>(serviceProvider)
{...
Note: If you are still using AddDbContext<MyDbContext>(options => ...) in startup it should pull those options automatically from the service provider. But you can also choose to either include the DbContextOptions as a parameter in the constructor or override the OnConfiguring() method for that.
I am giving you examples that create two separate DbContexts in a using block, but you should also be able to mix those with the regular "per-request" DbContext you would get injected in the controller's constructor.
Besides these options currently available I have created a new issue to track other possible improvements on how to create multiple instance of the same DbContext type in the same request:
https://github.com/aspnet/EntityFramework/issues/4441
I'm writing an app with DDD in mind and trying to avoid having an anemic domain model by delegating doman logic and behaviour to entities. There's an issue I'm running into with constructing entities that are aggregate roots and need to create sub-entities that require handling by a factory class. Here's an example:
I have the following entities: Page, Url and Layout. What makes a Page in my model is a Page with a Url and a Layout - without those two, a Page object would not be valid. In a simple model, the Page constructor method would simply create those two objects as private attributes. However, the Url has a specific requirement; it has to be created from the Page's title - or a slug - and it has to be unique (ensured by appending "-1", "-2", or something similar). This requires communication with a repository.
My initial idea was to pass/inject a UrlFactory object to the Page constructor and have the Page create the Url it needs, but I keep reading about how injecting services into entities is a bad idea.
So, my question is; is there a way - or an established pattern - to allow entities to construct their complex sub-entities without having an anemic domain model, or is injecting a factory in case such as this a valid solution?
If you consider URL construction as a technical concern, you could have an UrlFactory in the Infrastructure layer
in C# :
public class UrlFactory
{
public string CreateUrl(string title)
{
var url = // ... construct URL from the title here
return _pageRepository.NextAvailableUrlLike(url);
}
}
and then call it from your Application layer service.
If you see it as a Domain concern, Url construction logic could be in a Domain Service instead. The line calling the repository would be moved to the Application layer Service :
public void CreatePage(string title)
{
var potentialUrl = _urlService.CreateUrl(title);
var realUrl = _pageRepository.NextAvailableUrlLike(url)
new Page(title, realUrl, ...); // do whatever you want with the new Page instance
}
Do not inject factory class into aggregrate, use factory method instead. Then create method "validate(Validator)" in aggregate (Aggregate will only know it can be valided, but it will not implement logic how to do it).
Validator class which will be passed as parameter to your validate method, will need to have one method ->validateObject(this).
You pass instance of aggregate into validateObject so it will have access to your properties.
Validator class can have injected repository. When you run validateObject method it will search database for uniquness.
I know we can create singleton classes using the factory in Dart. But i happen to recall reading somewhere, classes registered using type(MyController) or type(MyServiceClass) happen to be singleton on their own.
Is that true? If so, does it apply to just classes registered with type(MyController) or does it use the annotation #NgController, etc. How does that impact the service and factory classes we write.
Also, where can i find a doc or link explaining the same.
Short answer: No, NgControllers are not singletons. The long answer discussed hierarchial dependency injection and the AngularDart template compiler.
Dependency Injection (DI)
The basic setup for DI is to create a single instance for each type registered with the DI system. Types are registered through modules before the injector is created. Once the injector is created, it will create instances on-demand.
var injector = new Injector([
new Module()
..type(SomeClass)
..value(AnotherClass, new AnotherClass('toplevel'))]);
Hierarchical DI
AngularDart uses a hierarchical DI system, which allows us to "shadow" types in the injector by creating child injectors. Consider
var childInjector = new Injector.fromParent([
new Module()..type(AnotherClass, implementedBy: AnotherSubclass)], injector);
If you get the AnotherClass type from the first injector, you will get the "toplevel" AnotherClass. From the childInjector, you will get an instance of AnotherSubclass. However, both injectors share the same instance of the first registered type, SomeClass.
AngularDart's Compiler
When Angular instantiates a template, it walks the template's DOM looking for elements that match directive selectors. When it finds an element which matches one or more directives, it will create a new child injector for that element. It then uses the new child injector to create directives.
This means that you have a hierarchical injector structure which mirrors the DOM structure. When the same directive is created for two different elements, they are created in two different injectors.
However, since directives can request other directives from the injector (say in their constructor), it is possible for two directives to share the same instance of a second if the second directive was created on a shared parent injector.
Directive selectors and significant types
When the compiler is created, it gets a list of all registered directives and their selectors. It does this by asking the DI system for all types annotated with #NgAnnotation. #NgDirective, #NgComponent, #NgController are all subtypes of #NgAnnotation, so they are included in that list.
This is why you may have two types, MyController and MyService, in the same module but only have one, MyController, be used by the compiler.
Angular 2 Dart
DI maintains a single instance per provider.
DI looks from the providers of a component that requests a dependency (constructor parameter) to the providers of the parent component, then the parent of this parent, up to the root component, and then further to the providers added at bootstrap(AppComponent, [/* providers */]) and the providers provided by Angular itself.
The instance of the first provider found this way is injected.
If there are more providers, there are more instances.
If there are providers registered in #Component(...), then there is a different instance for each provider on every component instance.
Angular 1 Dart
From the same injector you get the same instance every time when you request an instance of a specific type.
But in angular the injectors are hierarchical (similar to scope).
When you request a type it is looked up the hierarchy upwards for an injector that has that type registered and this injector returns the same instance every time.
If you apply the same selector for your controller to multiple DOM elements you get a new controller instance each time because there gets a new injectors instance created which gets some types registered like the controller and the element the controller was applied to. That injector returns its own instance when you request a type it has registered.
I'm using Unity to resolve types dynamically for a pluggable architecture. I'm also using interception to apply business rule validation via AOP (using ValidationAspects). Finally, I'm using NHibernate as an ORM to persist domain objects.
In order for AOP to work, we use the VirtualMethodInterceptor, as interface interception doesn't work with NHibernate. I have a facade over ISession that handles casting between interface and real types for repository operations.
To make sure that all objects in the graph fetched via NHibernate are properly proxied for AOP, I made an NH IInterceptor implementation and overrode the Instantiate() method, so I could supply NH with created objects rather than have it call new(). I then use Container.Resolve() to get back proxied objects with the validation injected, and give this back to NH to populate. This works OK.
The problem comes when the session flush occurs. NHibernate gets upset because the objects it sees in the graph are of the proxy type rather than the real type. The way we're mapping (all via property, all virtual) NH should be able to get all the values it needs via the proxy, if I could override the type-checking.
What I need to know is: given a transparently proxied object created by Unity with Interception enabled, is there a) any way to obtain a direct reference to the 'real' instance it's proxying, or b) to override NH and tell it to treat objects of a proxy type as if it were of a known mapped type, dynamically at runtime?
We use interception for caching. So in our class, that implements ICallHandler we have code like this:
public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
{
//...
var nextHandler = getNext();
var realReturn = nextHandler(input, getNext);
var cacheRefreshingItemParameters = new CacheRefreshingItemParameters
{
InterfaceMethod = input.MethodBase,
InterfaceType = input.MethodBase.DeclaringType,
TargetType = input.Target.GetType() //remember original type
};
_cacheProvider.Add(cacheKey, realReturn.ReturnValue, cacheRefreshingItemParameters);
//...
return (cachedReturn);
}
We put cacheRefreshingItemParameters in cache UpdateCallback and then resolve original service:
var service = _unityContainer.Resolve(parameters.TargetType);