在许多应用程序中，指定的类需要使用组件对象。IoC模式允许父对象（在WebWork中是XWork的ComponentManager实例）给与Action对象它所需要的资源对象，而不是该对象需要自己去获得资源对象。
有两种方法实现IoC：实例化和使用enabler接口。
l 实例化：在Action对象实例化时，将资源对象作为构造函数参数传递。
l 使用enabler接口：XWork使用enablers传递组件对象。Action实现enabler接口，带有叫做setComponent(ComponentObject r)的方法。这样，在该对象实例化时，资源对象就会传递给该对象。
为什么使用IoC？
使用IoC意味着你可以自上而下的方式开发组件，不需要创建客户程序需要调用的注册类，并自己去获得组件实例。
传统方式实现服务，大概下面有类似的步骤：
l 编写组件（例如ExchangeRateService）；
l 编写客户类（XWork的Action类）；
l 编写保持组件对象的注册类（例如Registry）；
l 写代码注册组件（例如Registry.registerService(new MyExchangeRateService())）；
l 在客户类中使用注册类获得服务（例如ExchangeRateService ers = Registry.getExchangeRateService()）
l 在客户类中调用组件（例如String baseCurrencyCode = ers.getBaseCurrency()）
使用IoC，包括下面的过程：
l 编写组件（例如ExchangeRateService）；
l 在XWork中注册组件类（例如componentManager.addEnabler (MyExchangeRateService, ExchangeRateAware)））；
l 编写实现enabler接口的客户类（例如实现ExchangeRateAware接口的Action类）；
l 直接在客户类中调用组件（例如String baseCurrencyCode = ers.getBaseCurrency()）
使用IoC有下面一些好处：
l 更容易测试：你可以使用enabler的方法传递模拟对象来更容易的测试你的对象；而不是必须建立整个容器环境来获得需要的组件对象（与容器环境无关）；
l 组件描述自己：在实例化组件时，你很容易决定什么是它需要的依赖关系，而不需要在代码中或运行错误中查找；
l 使用反射机制很容易发现依赖关系：这对图表生成和运行时优化都有好处；
l 当单独一个类保持应用所有的组件时，避免super-uber-mega-factory模式；
l 坚持Demeter原则：每个类只包含它实际使用的内容，这就鼓励小的特定功能的类，而使得设计干净；
l 允许所有上下文环境独立和明确的相互传递：本地线程在一个Web应用中可以很好的工作，但不适合高迸发的异步应用程序（如消息驱动应用程序）；
扫一扫
759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
