CAL 2: Container)

Container:

Programs implemented based on CAL are composed of loosely coupled modules. These modules need to interact with Shell to implement data presentation and user operations. Because they are loosely coupled, they need an interactive and communication method to implement the required business functions.

To work with these different modules, CAL-based applications use dependency injection containers. Dependency injection containers can reduce dependencies between objects. containers can help us instantiate and maintain the lifecycle of a class instance. These are based on the container configuration. During the creation of an object, the container injects all the instances required for this object. If the required instance has not been created, the container will first create and then inject it. Sometimes, the container needs to inject itself into the object. For example, a module needs to be injected into a container so that the module can register its view and service to the container.

Container Service has the following benefits:

1. Container saves your trouble: You need to use a component to understand its dependencies and create and destroy it.
2. When a container is used, your class does not need to be changed when the implementation of components required by your class changes.
3. The container makes it easier for you to test because you can use a false dependency.
4. Containers make the system easy to maintain, because a component can be easily added in.

For CAL: Containers have the following benefits:

1. The container injects the dependency of a module during its loading.
2. The container is used to register presenter and view.
3. The container creates Presenter and model and injects them into the view.
4. Containers can inject services, such as regionmanager and event aggregator.
5. A container can be used to register services related to a module.

The following code demonstrates how injection works. When PositionModule is created by container, it is injected into regionManager and container. In the RegisterViewsAndServices method, service, view, and presenter are both registered.

PublicPositionModule (IUnityContainer container, IRegionManager regionManager)

{

_ Container = container;

_ RegionManagerService = regionManager;

}

 

Public voidInitialize ()

{

RegisterViewsAndServices ();

...

}

 

Protected voidRegisterViewsAndServices ()

{

_ Container. RegisterType <IAccountPositionService, AccountPositionService> (new ContainerControlledLifetimeManager ());

_ Container. RegisterType <IPositionSummaryView, PositionSummaryView> ();

_ Container. RegisterType <IPositionSummaryPresentationModel, PositionSummaryPresentationModel> ();

...

}

Use Container

Container has two main purposes: Registration and resolution.

Registration:

Before you inject dependencies on an object, the dependent type must be registered to the container. To register a type, you must pass it to the container for an interface and the specific type for implementing this interface. You can register by code or configuration.

You can use the code to register the type and object to the container.

1. You can register a type or map it to the container. When appropriate, the container will create an instance of the type you specified.
2. You can register a generated object to the container. The container returns a reference to this object.

This. container. RegisterType <IEmployeesController, EmployeesController> ();

The above code is registered using the first method.

The type registered to the container has a lifetime, which can be singleton or instance (each time a new one is created ). The lifetime can be specified at registration or in the configuration file. The default lifetime is determined by the container implementation. For example, the Unity container uses the instance mode by default.

Resolving)

After a type is registered, it can be parsed or injected as a dependency.

Generally, when a type is parsed, there are three situations:

1. If this type is not registered, container throws an exception.

2. If this type is registered as a singleton mode, the container will return a singleton instance. If this is the first request, create one and keep this instance for future use.

1. If this type is not singleton, an instance is generated and the reference to the instance is not retained.

The following code resolves a type from the container:

EmployeesPresenterpresenter = this. container. Resolve <EmployeesPresenter> ();

However, the constructor of the EmployeesPresenter has the following dependencies, which are injected into the instance during type parsing.

PublicEmployeesPresenter (IEmployeesView view, IEmployeesListPresenter listPresenter, IEmployeesControlleremployeeController)

{

This. View = view;

This. listPresenter = listPresenter;

This. listPresenter. EmployeeSelected + = newEventHandler <DataEventArgs <businesstities. Employee> (this. OnEmployeeSelected );

This. employeeController = employeeController;

View. SetHeader (listPresenter. View );

}

When to use containers?

Consider whether it is appropriate to use containers for registration and resolution.

Whether your application can accept the performance consumed by registration and resolution. Because reflection is used in containers.

If the dependency is too large or the level is too deep, the performance consumption will increase significantly.

If a component does not have any dependencies or other types do not depend on it, it makes no sense to put it in the container.

Is singleton used for object survival?

If a component is a global service, such as log, we register it as a singleton mode.

If a component provides State sharing to multiple customers, you can register it as a singleton mode.

If some dependencies require a new instance each time, you can register it as a non-singleton mode.

Consider whether you configure the container through code or configuration files.

If you want to centrally manage different services, you can configure them through the configuration file.

If you want to register different services according to different situations, you need to configure them through code.

If you have module-level services, use code to register these services, because this allows you to register services only when the module is loaded.