最新评论
浪迹福州1 2009-04-28 11:20
请问http://wiki.entlib.net.cn为何不能访问了,企业库3.1的中文文档在别的地方有么,像原来wiki.entlib.net.cn那么全的
您还打算翻译企业库4.1的文档么?
您还打算翻译企业库4.1的文档么?
gongxiaohu 2008-11-21 17:53
@自由、创新、研究、探索……
...windsor和spring.net也有属性注入的好不好,你就一2
...windsor和spring.net也有属性注入的好不好,你就一2
baal 2008-06-14 23:19
这个好像翻译了 英文的帮助,很生硬,原文也不好,太简单,
我单步调式代码后发现,有些细节上根本不是这样,比如:
“当系统实例化 MyApplication 类时,它检测属性确定这是否是一个类型为 MyListener 的监听程序” 我仔细看了看,并不是把MyApplication 实例化的时候 就确定 MyListener 的 。具体的 确定监听,是 依赖注入容器的 ObjectBuilder。要找到 代码中真正的 把分离的 事件和 处理程序 绑定一起的,还是比较麻烦,因为是ObjectBuilder中的代码来做的,而在entlib中,那些代码是外部代码。
希望能写一些带有自己理解的文章。
我单步调式代码后发现,有些细节上根本不是这样,比如:
“当系统实例化 MyApplication 类时,它检测属性确定这是否是一个类型为 MyListener 的监听程序” 我仔细看了看,并不是把MyApplication 实例化的时候 就确定 MyListener 的 。具体的 确定监听,是 依赖注入容器的 ObjectBuilder。要找到 代码中真正的 把分离的 事件和 处理程序 绑定一起的,还是比较麻烦,因为是ObjectBuilder中的代码来做的,而在entlib中,那些代码是外部代码。
希望能写一些带有自己理解的文章。
JesseZhao 2008-06-06 18:51
最近看到很多这个东西
不错
enterprise library新的东西,应该会搅起一场腥风血雨
不错
enterprise library新的东西,应该会搅起一场腥风血雨
Dorian Deng 2008-05-22 23:53
@浪子
@紫色阴影
@b4nc
以上我们讨论的问题,我会在《深入 Unity 1.x 之四》中给出一个满意的答案,而且是一个大家都期待的答案。
@紫色阴影
@b4nc
以上我们讨论的问题,我会在《深入 Unity 1.x 之四》中给出一个满意的答案,而且是一个大家都期待的答案。
紫色阴影 2008-05-22 10:53
@Dorian Deng
DI可替换是经常会遇到的。
Program类使用Unity是没有问题的,但是上面所写的方法是从容器中获得对象显式给属性赋值,不够透明
要透明的话被注入的类的属性就得加上[Dependency]吧,这样又太侵入了
当然这里可以用Factory
这篇文章有些观点说得很好http://ayende.com/Blog/archive/2008/02/24/Reviewing-Unity.aspx
DI可替换是经常会遇到的。
Program类使用Unity是没有问题的,但是上面所写的方法是从容器中获得对象显式给属性赋值,不够透明
要透明的话被注入的类的属性就得加上[Dependency]吧,这样又太侵入了
当然这里可以用Factory
这篇文章有些观点说得很好http://ayende.com/Blog/archive/2008/02/24/Reviewing-Unity.aspx
Dorian Deng 2008-05-22 06:45
@紫色阴影
我指的是示例中的 Program 类,假如要在其中使用 Unity 来获取对象,如果不用其 API,又如何称为使用了 Unity?好绕的问题
如果连 DI 容器也要求可替换的,那就需要自己写代码来做成 Provider,这不就将问题复杂了,也失去了使用 DI 的好处。
我指的是示例中的 Program 类,假如要在其中使用 Unity 来获取对象,如果不用其 API,又如何称为使用了 Unity?好绕的问题
如果连 DI 容器也要求可替换的,那就需要自己写代码来做成 Provider,这不就将问题复杂了,也失去了使用 DI 的好处。
浪子 2008-05-21 22:02
@紫色阴影
想知道.net/java底下哪些IoC容器是非侵入性,thanks in advance.^_^
想知道.net/java底下哪些IoC容器是非侵入性,thanks in advance.^_^
浪子 2008-05-21 22:01
嗯.没错.
所以说对于需要非侵入性的IoC容器,适用两个场景:
1.现有程序,需要加入IoC来做对象注入
2.可以预见未来有可能会替换IoC容器的provider
如果这两种情况就需要非侵入性的.
--引用--------------------------------------------------
紫色阴影: 如果现在有一大堆code存在,而需要加上IOC,难道要所有需要注入的地方都得改code?
而且非侵入性的也容易替换
--引用--------------------------------------------------
浪子: 明白了,b4nc是要做完全的零耦合啊。
不过没仔细衡量过这样子做是为了解决什么问题?似乎没人整天换IoC容器?
--------------------------------------------------------
--------------------------------------------------------
所以说对于需要非侵入性的IoC容器,适用两个场景:
1.现有程序,需要加入IoC来做对象注入
2.可以预见未来有可能会替换IoC容器的provider
如果这两种情况就需要非侵入性的.
--引用--------------------------------------------------
紫色阴影: 如果现在有一大堆code存在,而需要加上IOC,难道要所有需要注入的地方都得改code?
而且非侵入性的也容易替换
--引用--------------------------------------------------
浪子: 明白了,b4nc是要做完全的零耦合啊。
不过没仔细衡量过这样子做是为了解决什么问题?似乎没人整天换IoC容器?
--------------------------------------------------------
--------------------------------------------------------
Dorian Deng 2008-05-21 19:16
@紫色阴影
是否被侵入是针对服务提供对象而言的,对于服务使用对象进行这样的讨论没有意义。
是否被侵入是针对服务提供对象而言的,对于服务使用对象进行这样的讨论没有意义。
紫色阴影 2008-05-21 18:06
如果现在有一大堆code存在,而需要加上IOC,难道要所有需要注入的地方都得改code?
而且非侵入性的也容易替换
--引用--------------------------------------------------
浪子: 明白了,b4nc是要做完全的零耦合啊。
不过没仔细衡量过这样子做是为了解决什么问题?似乎没人整天换IoC容器?
--------------------------------------------------------
而且非侵入性的也容易替换
--引用--------------------------------------------------
浪子: 明白了,b4nc是要做完全的零耦合啊。
不过没仔细衡量过这样子做是为了解决什么问题?似乎没人整天换IoC容器?
--------------------------------------------------------