| « | August 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | |
|
公告 |
|
关注电子政务、大型企业应用开发、Web、Workflow、MOM、MDA、RCP、GEF email:gmluyang@gmail.com
|
| Blog信息 |
|
blog名称:SixSun的Blog
日志总数:152
评论数量:372
留言数量:13
访问次数:2376793
建立时间:2004年12月13日 |
| |
|
 [Spring]Spring-IoC
随笔, 读书笔记
SixSun 发表于 2006/4/11 0:02:03 |
|
Spring 的核心概念是 IoC，IoC 的抽象概念是「依赖关系的转移」
Spring 所采用的是Dependency Injection 来实现 IoC，中文翻译为依赖注入，依赖注入的意义是：保留抽象接口，让组件依赖于抽象接口，当组件要与其它实际的对象发生依赖关系时，通过抽象接口来注入依赖的实际对象。
设计原则：
高层模块不应该依赖低层模块，而是模块都必须依赖于抽象；在模块设计时，高层的抽象模块通常是与业务相关的模块，它应该具有重用性，而不依赖于低层的实现模块，如果高层模块直接调用低层模块，则就对低层模块产生了依赖关系。低层模块的更动造成了高层模块也必须跟着更动，这不是一个好的设计方式，在设计上希望模块都依赖于模块的抽象，这样才可以重用高层的业务设计。
实现必须依赖抽象，而不是抽象依赖实现；如果以面对对象的方式来设计，依赖反转（Dependency Inversion）的解释变为程序不应依赖具体实现，而是依赖于抽象，实现必须依赖于抽象。(有点拗口500)this.width=500'>)Dependency Inversion 的意思即是程序不依赖于实作，而是程序与实现都要依赖于抽象。 IoC 的 Control 是控制的意思，其实其背后的意义也是一种依赖关系的转移，如果A依赖于B，其意义即是B拥有控制权，您想要转移这种关系，所以依赖关系的反转即是控制关系的反转，藉由控制关系的转移，可以获得组件的可重用性。程序的业务逻辑部份应是可以重用的，不应受到所使用框架或容器的影响，因为可能转移整个业务逻辑至其它的框架或容器，如果业务逻辑过于依赖容器，则转移至其它的框架或容器时，就会发生困难。
应用程序不应依赖于容器，而是容器服务于应用程序；
不要向容器要求您所需要的（对象）资源，容器会自动将这些对象给您！」。IoC 要求的是容器不侵入应用程序本身，应用程序本身提供好接口，容器可以透过这些接口将所需的资源注至至程序中，应用程序不向容器主动要求资源，故而不会依赖于容器的组件，应用程序本身不会意识到正被容器使用，可以随时从容器中脱离转移而不用作任何的修改，而这个特性正是一些业务逻辑中间件最需要的。
|
|
|