Introduction to Di in Tapestry 5

Di is the dependency injection abbreviation, which we translate as "dependency injection". Simply put, the establishment of two object A->b (or component) dependencies, it is best not to be determined at the time of programming, that is, do not determine the dependencies by new way, this way will make the system lose scalability, reusability and so on. When the business requirements change, A is no longer dependent on B but rely on C (A->C), the new way to establish a dependency when you have to modify A, which is the most we do not want to see in the system design. What we need is a->b or a->c dependencies that are not fixed, dead, but flexible and variable. If the dependencies can be postponed to the runtime, the dynamic "inject" in this design is what we want. So we don't need to change a dependency by modifying a. The design idea of DI ("Dependency Injection") is that dependencies are deferred to the runtime.

Figure 1.28

Figure 1.28 is a schematic diagram of the spring Framework implementation Di, and in figure 1.28 we see whether a object relies on a B object or whether the C object is passed through spring The framework is set up at runtime by Beanfactory to read the Applicationcontext.xml file, rather than being determined by the new method at the time of programming.

The thought of Di was long in the Ooad, and Rod Johnson fully integrated the thought of Di into the spring framework design. As we learn more, you will find that the spring framework is a multiple bean that builds dependencies through Di and builds a complex network of dependencies, as shown in Figure 1.29. The upper Bean relies on the next layer of beans and the dependencies can be easily switched, and the upper Bean does not need to modify any code.

Figure 1.29