IOC problem domain

Document directory

• 1. How to easily support the product environment and test environment during deployment, that is, provide different implementations of the same interface in different environments
• 2. How to simplify the configuration so that the framework can automatically identify Dependencies
• 3. How to dynamically switch different implementations of the same type during the runtime? For example, if the read-only mode is selected, all save operations should be ignored and will not do anything, you can achieve this by providing the dummy version of the Save operation.
• 4. In a multi-user environment, how to ensure that each user has its own object combination without mutual interference
• 5. How to manage the object Lifecycle

One unavoidable problem for IOC is how to modularize the application, because IOC usually provides good support for a single object, such as dependency management and lifecycle management, configuration during deployment or even running, but usually a group of collaborative objects constitute the basic building blocks of the application. the collaboration relationships between these cohesion objects are implementation details, including the constructor and attributes of a single object. If you expose these relationships, you can certainly improve the flexibility, however, it takes the complexity of the Final deployment phase and the difficulty of maintainability. taking the configuration file as an example, you may need to modify seven or eight attributes in the configuration file that contains hundreds of object definitions, and change five or six implementations to adapt to different runtime environments.

There are two ways to solve this problem. One is that the IOC framework provides modular support and supports deployment. The other is that the IOC framework should avoid this problem. This is not within the scope of IOC, it should be handled by a dedicated modular framework such as osgi.

In my relatively familiar IOC framework, autofac tries to provide the "module" concept to solve some problems. the collaboration between objects can be hidden in the module object. Some necessary parameters can be set through the module attribute. for users, only the module object can be exposed for deployment. this is at the cost of losing flexibility. The implementation of replacing an internal object becomes a hack, which must be completed through communication between team members and collective ownership of the source code. if you enumerate all the implementations of extension points within the module object and select an implementation by using the parameters during deployment, unnecessary dependencies will be introduced, which is worth the candle.

I personally prefer the second type. Who will introduce the modular framework on the. NET platform?

So focus a little bit on the issues that the IOC framework needs to solve when processing a single object.

1. How to easily support the product environment and test environment during deployment, that is, provide different implementations of the same interface in different environments

This does not even need to be solved by the IOC framework. application developers can provide different configuration files in different environments.

2. How to simplify the configuration so that the framework can automatically identify Dependencies

This is called auto wire. Generally, dependencies are matched based on the constructor parameters or attribute types.

3. How to dynamically switch different implementations of the same type during the runtime? For example, if the read-only mode is selected, all save operations should be ignored and will not do anything, you can achieve this by providing the dummy version of the Save operation.

Auto wire has certain limitations based on type matching, that is, the same runtime environment has multiple implementations of an interface. there is actually a concept, that is, the object identifier. the type is only one of the identifiers. another more adaptable identifier is the string. some frameworks are called ids, while others are called names. an important feature of identity is that it is unique in a runtime environment. the type identifier can also be converted to the string identifier, and the full name can be used. (the identifier itself is a concept that can be expressed by a class and then implemented by different sub-classes, such as type-based identifiers and string-based identifiers)

Therefore, there are two policies: one is to allow an object during the runtime to re-declare the dependency identifier, and the other is to replace the original implementation with an object with the same identifier during the runtime. the last one is relatively easy to implement. You can just register the last one win in the order of registration.

If multiple instances of the same type need to exist at the same time, different IDS can be assigned during deployment. However, another problem is that

4. In a multi-user environment, how to ensure that each user has its own object combination without mutual interference

The IOC framework is generally called an IOC container. the concept of container is the encapsulation of runtime environment and context. It provides a set of infrastructure and various services required during runtime. The most important thing is that, it provides isolation in the same process. in a multi-user environment, you can create multiple containers that are independent from each other. Each container is responsible for creating the required objects and providing the required services. as a result, new problems arise,

5. How to manage the object Lifecycle

Obviously, some objects are globally defined. During the program running, you cannot create or destroy multiple instances. some are associated with one operation and one request. The same object instance can be reused in the same request, but different requests must create different object instances. some users need to create a new instance each time they need to access it. the container must provide infrastructure so that the application developer can specify the object lifecycle and destroy all the destroyed objects at the end of the lifecycle. C # provides the dispose mechanism for use.

Other problems, such:

• How to support the composite, decorator, and proxy Modes
• How to facilitate user registration, including automatic registration
• How to inject objects created by containers to objects manually created by users
• How to integrate with existing frameworks
• How to Avoid circular reference: constructor/property Dependencies
• Open generics Injection
• List injection unregistered resolution
• Auto-mocking
• Startable
• Stronugly-typed activation events
• Adding to an existing container