| 澶辨晥閾炬帴澶勭悊 |
|
spring妗嗘灦澶栨枃鏂囩尞 PDF 涓嬭澆
鏈珯鏁寸悊涓嬭澆錛?/strong>
閾炬帴錛?a target="_blank">https://pan.baidu.com/s/1ETpYD-b5fu4w4KWqLupcxA
鎻愬彇鐮侊細(xì)qjri
鐩稿叧鎴浘錛?/strong>
涓昏鍐呭錛?/strong>
Dependency Injection
The concept of dependency injection (DI), objects are given their dependencies at construction time, is one of the foundations of the Spring Framework. You have also probably heard of Inversion of Control (IoC). IoC is a broader, more general concept that can be addressed in different ways. IoC lets developers decouple and focus on what is important for a given part of an enterprise application, but without having to think about what other parts of the system do. Programming to interfaces is one way to think about decoupling.
Almost every enterprise application consists of multiple components that need to work together. In the early days of Java enterprise development, we simply put all the logic of constructing those objects (and the objects those objects needed) in the constructor (see Listing 2-1). At first sight, there is nothing wrong with that approach; however, as time progressed, object construction became slow, and objects had a lot of knowledge they shouldn’t have had (see the Single Responsibility Principle). Those classes became hard to maintain, and they were also quite hard to unit and/or integration test.
The class from Listing 2-1 programs to interfaces, but it still needs to know about the concrete implementation of an interface simply to do object construction. Applying IoC by decoupling the construction logic (collaborating objects) makes the application easier to maintain and increases testability. There are seven ways to decouple this dependency construction logic:
1. Factory pattern
2. Service locator pattern
3. Dependency injection
a. Constructor based
b. Setter based
c. Interface based
d. Annotation driven
4. Contextualized lookup
When using the factory pattern, service locator pattern, or contextualized lookup, the class that needs the dependencies still has some knowledge about how to obtain the dependencies. This can make things easier to maintain, but it can still be hard to test. Listing 2-2 shows a contextualized lookup from JNDI (Java Naming and Directory Interface). The constructor code would need to know how to do the lookup and handle exceptions.
The immediately preceding code isn’t particularly clean; for example, imagine if there were multiple dependencies from different contexts. The code would quickly become messy and increasingly hard, if not impossible, to unit test (see Chapter 9 for more information on testing).
|
| Java1234瀹樻柟緹?5錛?/td> | 
|
| Java1234瀹樻柟緹?5錛?/td> | 838462530 |
鑻忓叕緗戝畨澶?32061202001004鍙?/p>
