Question

The common Prism’s way of designing complex applications is to have each module implementing an IModule interface to Initialize itself for being able to work.
In most cases this “initialization” is mostly about registering some types with an IoC container. So, in our case IModule usually looks like this:

public class Module : IModule {
    private IUnityContainer _container;
    public Module(IUnityContainer container) {
        _container = container;
    }

    public void Initialize() {
        //register public types
        _container.RegisterType<IMyPublicInterface, MyImplementation>();


        //register internal dependencies
        _container.RegisterType<IInternalDependency1, InternalDependency1>();
        _container.RegisterType<IInternalDependency2, InternalDependency2>();
        //..etc.
    }
}

Our modules usually have only one(or very few) public types, and much more internal classes/dependencies to register.

I’m a little bit worried, if that approach breaks an encapsulation principle?
It seems, that we’re registering everything (both internal and public types) within one global container, which could blur the module’s border (public and internal types registration is completely the same) and make potentially possible to .Resolve our “internal” classes in the other places.

Isn’t it better to register internal dependencies within a ChildContainer?

Or may be we’re doing something completely wrong? 🙂

Answer 1

Your question has the answer modules register their views and view models in child containers. Only sharable services are registered in global container.