Castle unveiling 2--ioc (1)

Castle IOC is the core and soul of Castle. In one sentence, if you want to understand frameworks such as castle and spring, you must first understand their IOC. Of course, you do not need to stay at the usage level. This chapter helps you uncover the essence of Castle IOC.

Di and IOC are popular architectural design ideas and methods. IOC is to reverse the original internal control of the object to the class, also known as Dependence Injection. The core idea of IOC or DI is to provide a simpler mechanism to define dependencies between components (usually involving object cooperation) and manage dependencies in their lifecycles. IOC provides such a service that allows a component to access its dependencies and services in its lifecycle. In general, IOC can be divided into two types of words: dependency injection and dependency search. In this sense, we always talk about IOC when talking about Di, but it doesn't necessarily involve DI when talking about IOC. for details about their principles and theories, refer to otherArticle.

1. IOC Lifecycle

A) Castle. Core. lifestyletype

Here we focus on the following values:

• Singleton: Compared to transient, if a component with the corresponding type or key is created at a time, it is activated and returned. Shared by each consumer or client
• Thread: for thread-level types, each thread has a unique instance.
• Transient: each time the container creates an instance of the corresponding type. Stateless
• Perwebrequest: each time an HTTP Web request is created.

In addition, pooled is the optimization of transient, and I guess it is a small-scale instance reuse. Between singleton and transient.

The lifecycle value can be configured as declarative attribute and in the configuration file. Whatever the principle is the same, the reflection call will be returned.

Two call Methods

Configuration-based:

 
1: <Component ID= "Glquotecalculator"
 

  2:   service   =" Aspen. apt. casualty. bll. businessfacade. glquotecalculator, Aspen. apt. casualty. bll " 

3:Type= "Aspen. Apt. Casualty. BLL. businessfacade. glquotecalculator, Aspen. Apt. Casualty. BLL" Lifestyle= "Transient" /> 
 

Attribute declaration:

 
1:[Transactional]
 

2:
 

 
3:[Singleton]
 

 
4:
 

5: Public Partial ClassGlquotemanager: quotemanagerbase
 

For attribute configuration, Castle. Core defines the following attribute

Customertypeattribute extends lifestyletype. Custom by passing in a custom type. Pooled defines the poolInitial sizeAnd Max size. Of course, you can pass in the repaired attribute when setting the attribute. Here, castlecomponentattribute is used to register the component lifestyle in batches by passing in the key, type, and lifestyletype. This will be discussed in detail later.

2.IOCInjection Method

L. The method-based IOC (Type-0) method is very simple. It provides a method to pass in the dependent type (client. In some cases, this method is used to consume the client.CodeOmitted

L Interface-based IOC (Type-1) is simple,Aggressive

 
1: Public ClassSport {
 

2: PrivateInterfaceball ball;// Interfaceball is the defined interface
 

 
3: Public VoidInit (){
 

4: // Basketball implements the interfaceball Interface
 

 
5:Ball = (interfaceball) class. forname ("Basketball"). Newinstance ();
 

6:}
 

 
7:}
 

In the above Code, sport depends on the implementation of interfaceball. How can I obtain an instance of the interfaceball implementation class? The traditional method is to create an interfaceball implementation class instance in the Code and assign it to the ball. In this way, sport depends on the implementation of interfaceball during the compilation period. In order to separate callers and implementers during the compilation period, with the above Code, we dynamically load the implementation class according to the class name of the implementation class set in the configuration document in advance, and use interfaceball to force the transformation for sport. This is a prototype of interface injection. For a type1 IOC container, the implementation of the load interface and the creation of its instance are completed by the container, such as the context commonly used in J2EE R & D. lookup (servletcontext. getxxx) is a type 1 IOC representation. Apache avron is a typical type1 IOC container.

L setter-based IOC (type-2) setter-based dependency injection is the best choice, because it has the least impact on your code in non-IOC settings. This method is widely used by spring, and castle also supports this method. Detailed Decomposition

L construtor-based IOC, type-3) is a good choice when you need to confirm that the dependency will be passed to the component. But remember that many containers provide their own setter-based dependency injection mechanism for this situation. Castle supports this method. Detailed Decomposition

AboutIOCThe theory of the injection method is not described. Please refer to other articles.

Appendix: Several TypesIOCComparison of advantages and disadvantages

Comparison and summary of several dependency injection modes

Because the interface injection mode is invasive, the component must be associated with a specific interface. Therefore, the interface injection mode is not optimistic and is used in reality.

Advantages of constructing subinjection in type2:

1. "create a complete and legal object during the construction period". For this design principle, type2 is undoubtedly the best responder.

2. Avoids tedious compilation of setter methods. Any dependency is set in the constructor, and dependency is displayed in a centralized manner, making it easier to read.

3. Because there is no setter method, the dependency is set at one time by the container during construction.Therefore, after a component is created, the component remains unchanged.You do not have to worry about the failure of the component dependency caused by the setter method executed by the upper-Layer Code during the calling process. Especially for the singleton mode components, this may have a major impact on the entire system.

4. Similarly, since associations are expressed only in constructors, only the component creator needs to care about the dependencies within the component. For callers, dependencies in components are in the black box. Shielding unnecessary information on the upper layer also ensures the system's level of clarity.

5. Constructing subinjection means that we can determine the dependency injection sequence in the constructor. For a component that relies heavily on external services, the order in which dependencies are obtained may be very important, for example, a prerequisite for dependency injection is that the datasource and related resources of the component have been set.

Advantage of setting value injection in type3

1. For programmers who are used to the traditional research and development of JavaBean, it is more intuitive and natural to set the dependency through the setter method.

2. If the dependency (or inheritance relationship) is complex, the constructor in the type2 mode will also be quite large (we need to set any dependency in the constructor ), in this case, the type3 mode is more concise.

3. For some third-party class libraries, our components may need to provide a default constructor (such as the action in struts). In this case, the dependency injection mechanism of type2 reflects its limitations, it is difficult to complete our desired features.

It can be seen that the type2 and type3 modes have their own merits, while spring and picocontainer both provide good support for the dependency injection mechanisms of type2 and type3 types. This gives us more options. Theoretically, type2 is the main type, supplemented by the type3 type mechanism, which can achieve the best dependency injection effect. However, type3 is more widely used for applications developed based on Spring framework.

Not complete, To be continued...