Type 3 IOC :: Open Heart

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=32867 存档链接: https://web.archive.org/web/20040913192338id_/http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=32867

Open Heart Open Heart For Open World 关注JAVA和开放源码社区 <<<终于有别人也来看我的blog了 | 首页 | 搬家>>> Type 3 IOC 今天开始看IoC了，先主要看了PicoContainer的介绍，发现正是以前我想要得。 用于MVC中的M层，提供服务组件，自己以前也有一个非常简陋的实现，但是基于继承的，感觉不太好用，虽然能减轻一定的编码工作，但是基本上没有什么重用性可言，因为持久层也是用了自己实现的一个简陋模型，需要在外部控制事务，我的这个服务层，基本上也就是作了控制事务的封装，本意是想实现能够组合组件可以任意开启事务，最大程度上服用这些服务组件，虽然能用，好像并没有达到效果。 这个PicoContainer应该说能够解决问题了，gigix的分析很到位： “IOC也是个老词了，用它的另一个名字或许更容易理解――“好莱坞原则”：don't call us, we will call you. 也就是说，每个component是passive的，只有framework是active的，component的initialization和invocation都由framework管。” 具体讲到PicoContainer，号称是Type 3 IoC，怎么就变成Type3了呢？呵呵，让我的感觉是其实只是每个组件注册时候采用的方式不同，不过其他基本属性应该是一致的。 下边摘录了一下他们三种的区别： Type 1 IoC (the Avalon way) forces components to be decode their own configuration metadata. Too intrusive. Type 2 IoC (the XDoclet way) looks cleaner: metadata is separated from code (albeit not from the source). But there's more to composition than property setting. Type 3 IoC looks like an attempt to disguise compositional metadata by placing it in the least imaginable place: the component's constructor! Again, there's more to composition than property setting. pawa @ 2003-08-18 16:13 引用Trackback(0) | 编辑 评论 Type 3要求使用constructor，真不知道这究竟是好事还是坏事。Jon Tirsen说这种做法的好处在于：不必到处去找设置context的setXxx方法，所有的context必定是在ctor里设置。 想请你说说看，这种IoC Container究竟有什么用？我现在只是相信Rickard的眼光，其实并不太知道why、when、how to使用它。请你介绍一下？ gigix ( ) 发表于 2003-08-22 10:27 http://douleimi.vicp.net/space/IoC potian ( douleimi.vicp.net ) 发表于 2003-10-23 01:53 发表评论 最后更新 搬家 IoC Container Type 3 IOC 终于有别人也来看我的blog了 EclipseUml 一些AOP的基本知识 单独建立一个AOP的分类 究竟什么是Inversion of Control (or IoC for short)？ 如何构建框架？ TheServerSide Symposium 纯粹的技术座谈会