Unity in Modular App
-
I thinks that unity containers should check child containers instead of the parent container. That way, during registration after the manager registers global modules, it can pass a child container to every module to register it's services. Then resolution can then be done using the parent container after it's wrapped in an IServiceLocator. What do you think? The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
-
I thinks that unity containers should check child containers instead of the parent container. That way, during registration after the manager registers global modules, it can pass a child container to every module to register it's services. Then resolution can then be done using the parent container after it's wrapped in an IServiceLocator. What do you think? The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Why would you be wrapping the parent container in a service locator? You're providing IoC and then subverting it by using service location.
This space for rent
-
Why would you be wrapping the parent container in a service locator? You're providing IoC and then subverting it by using service location.
This space for rent
-
'Cause in resolution you don't want modules changing other modules services. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
I wasn't talking about the child container part - I got that. It was the use of the service locator I was questioning.
This space for rent
-
I wasn't talking about the child container part - I got that. It was the use of the service locator I was questioning.
This space for rent
IServiceLocator does not have a RegisterService(). So all modules will be able to use the services registered on the parent container (and child containers) without being able to block the configuration of child containers by adding services to the parent. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
-
IServiceLocator does not have a RegisterService(). So all modules will be able to use the services registered on the parent container (and child containers) without being able to block the configuration of child containers by adding services to the parent. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Nope, sorry - that didn't make much sense to me. Could you put a practical example here highlighting what you're trying to solve. BTW - don't forget - just because you have registered a child container in your module, this doesn't mean that the parent IUnityContainer is no longer available.
This space for rent
-
Nope, sorry - that didn't make much sense to me. Could you put a practical example here highlighting what you're trying to solve. BTW - don't forget - just because you have registered a child container in your module, this doesn't mean that the parent IUnityContainer is no longer available.
This space for rent
OK! // Registration phase 1. Manager creates a container and registers modules. 2. Manager passes a child container to every module to registers it's services. 3. Module1 register LegitLogger as ILogger. // Resolution 4. Manager passes root container to every module to able to find services added by other modules (on child containers). Without IServiceLocator wrap, Module2 can register DummyLogger as ILoger on the root container so that LegitLogger will never be found (child containers will not be searched). The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
-
Nope, sorry - that didn't make much sense to me. Could you put a practical example here highlighting what you're trying to solve. BTW - don't forget - just because you have registered a child container in your module, this doesn't mean that the parent IUnityContainer is no longer available.
This space for rent
As for what I'm trying to solve. In the current setup a module can only use it's services and the services registered on the root container, So modules cannot share there services. We could pass the root container to modules so they can register there services in a single pool, but then a module can intercept another module's services. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
-
OK! // Registration phase 1. Manager creates a container and registers modules. 2. Manager passes a child container to every module to registers it's services. 3. Module1 register LegitLogger as ILogger. // Resolution 4. Manager passes root container to every module to able to find services added by other modules (on child containers). Without IServiceLocator wrap, Module2 can register DummyLogger as ILoger on the root container so that LegitLogger will never be found (child containers will not be searched). The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
I'm a touch confused as to why you think you need to pass the child container in. Remember that unity looks for modules that implement IModule - so, create a base module class that takes the parent container and creates a child container internally. Something like this:
public abstract class ModuleBase : IModule
{
public IUnityContainer ParentContainer { get; private set; }public ModuleBase(IUnityContainer container)
{
ParentContainer = container;
Container = container.CreateChildContainer();
}
}With that, you have a segregated module architecture that will allow you to set up the interfaces how you like. I would tend to create a fluent architecture here to simplify the registration in here, but that's just me.
This space for rent
-
I'm a touch confused as to why you think you need to pass the child container in. Remember that unity looks for modules that implement IModule - so, create a base module class that takes the parent container and creates a child container internally. Something like this:
public abstract class ModuleBase : IModule
{
public IUnityContainer ParentContainer { get; private set; }public ModuleBase(IUnityContainer container)
{
ParentContainer = container;
Container = container.CreateChildContainer();
}
}With that, you have a segregated module architecture that will allow you to set up the interfaces how you like. I would tend to create a fluent architecture here to simplify the registration in here, but that's just me.
This space for rent
In that setup the following code is possible:
public class DefectiveModuel : IModule
{
public DefectiveModuel(IUnityContainer container)
{
// trash the container
}
}The setup I'm going for is more like:
public interface IModule
{
void RegisterServices(IUnityContainer container);
void Init(IUnityContainer container);
}
public class Manager
{
public void Init(IUnityContainer root)
{
// Do something with the container
Modules.Foreach(m => m.RegisterServices(root.CreateChildContainer()));
Modules.Foreach(m => m.Init(root.Wrap()));
}
}So modules will only be able to configure there child container. However, they will be able to use the root container to access services added by other modules on child containers under root.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
-
In that setup the following code is possible:
public class DefectiveModuel : IModule
{
public DefectiveModuel(IUnityContainer container)
{
// trash the container
}
}The setup I'm going for is more like:
public interface IModule
{
void RegisterServices(IUnityContainer container);
void Init(IUnityContainer container);
}
public class Manager
{
public void Init(IUnityContainer root)
{
// Do something with the container
Modules.Foreach(m => m.RegisterServices(root.CreateChildContainer()));
Modules.Foreach(m => m.Init(root.Wrap()));
}
}So modules will only be able to configure there child container. However, they will be able to use the root container to access services added by other modules on child containers under root.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Unfortunately, because the parent container is still available to you, there's nothing stopping the inner services from trashing the root container - all they need to do is get the Parent from your IUnityContainer; you're not going to be able to prevent that.
This space for rent
-
Unfortunately, because the parent container is still available to you, there's nothing stopping the inner services from trashing the root container - all they need to do is get the Parent from your IUnityContainer; you're not going to be able to prevent that.
This space for rent
:( Just noticed. Edit: However, It's still hard to predict the order in which the modules will be called. Edit2: If there was an IServiceRegister interface. Then we could use it to wrap the container during registration. "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
-
As for what I'm trying to solve. In the current setup a module can only use it's services and the services registered on the root container, So modules cannot share there services. We could pass the root container to modules so they can register there services in a single pool, but then a module can intercept another module's services. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
aboubkr90 wrote:
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Please do not apply that philosophy to daily traffic.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
:( Just noticed. Edit: However, It's still hard to predict the order in which the modules will be called. Edit2: If there was an IServiceRegister interface. Then we could use it to wrap the container during registration. "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
I have handled this, in the past, by hiding the module registration. This works by putting a proxy registrar in place and then exposing this through the module registration instead. At some point, I'll put out an article describing how I did this (part of the idea behind this is that this approach makes it easier to swap IoC containers around).
This space for rent
-
I have handled this, in the past, by hiding the module registration. This works by putting a proxy registrar in place and then exposing this through the module registration instead. At some point, I'll put out an article describing how I did this (part of the idea behind this is that this approach makes it easier to swap IoC containers around).
This space for rent
:thumbsup:Good idea. PS: I just thought of the idea of having to replace all those IUnityContainer references. That is one scary thought. ____________________________________________________________________________________________________ "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
-
aboubkr90 wrote:
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Please do not apply that philosophy to daily traffic.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Good thing i don't have a license. :-D ____________________________________________________________________________________________________ "The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke