You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have solutions with many modules/components. Often, modules logically encapsulate internal containers. Services in these containers should not be visible from the outside, or this is not necessary. At the same time, services may need upstream container services through dependency injection.
For example:
Container Web Controllers. Controllers exist at a high UI / API level, but have a dependency on the level of data access. Model levels neither about UI, nor about API do not reflect.
Calculator function container. Calculator functions exist in a low-level sandbox. There is no sense in having access to them from outside (their descriptions are enough), but the functions themselves may require access to the functionality of individual modules.
Thus, registering such services in a common container will, firstly, overload it, and secondly, give access to logically inaccessible components.
To solve this problem, I use child containers. They are not an extension of the outer scope or context. They expand the registration of services. What do you think about it?
public static class ContainerExtension
{
private static readonly ConcurrentDictionary<ServiceContainer, Action<object>> proccessors = new ConcurrentDictionary<ServiceContainer, Action<object>>();
public static TContainer CreateSubContainer<TContainer>(this ServiceContainer parent)
where TContainer : ServiceContainer, new()
{
return parent.CreateChildContainer(() => new TContainer());
}
public static TContainer CreateChildContainer<TContainer>(this ServiceContainer parent, Func<TContainer> childFactory)
where TContainer : ServiceContainer
{
proccessors.TryGetValue(parent, out var parentProccessor);
if (parentProccessor == null)
{
parentProccessor = x => parent.InjectProperties(x);
}
var child = childFactory();
child.Initialize(x => true, (factory, instance) => parentProccessor(instance));
proccessors.TryAdd(child, instance =>
{
parentProccessor(instance);
child.InjectProperties(instance);
});
return child;
}
}
The text was updated successfully, but these errors were encountered:
I have solutions with many modules/components. Often, modules logically encapsulate internal containers. Services in these containers should not be visible from the outside, or this is not necessary. At the same time, services may need upstream container services through dependency injection.
For example:
Thus, registering such services in a common container will, firstly, overload it, and secondly, give access to logically inaccessible components.
To solve this problem, I use child containers. They are not an extension of the outer scope or context. They expand the registration of services. What do you think about it?
The text was updated successfully, but these errors were encountered: