有不好的一面吗?我觉得现在几乎要依赖它了。每当项目超过一定规模时,几乎感觉到对标准模式的过敏反应,并立即用依赖注入框架重新连接它。
我发现的最大问题是,对于刚刚学习它的其他开发人员来说,这可能会让人感到困惑。
另外,如果它是我使用的语言的一部分,我会感觉好多了。虽然,至少对于Java来说,有一些非常轻量级的库非常好。
思考?糟糕的经历?或者只是不要担心它?
[编辑] Re:依赖注入本身的描述
抱歉模糊不清。 Martin Fowler可能比我更好地描述了它...没有必要浪费精力。
巧合的是,这证实了有关它的一点,它仍然没有被广泛实践,并且如果每个人都没有加快速度,那么在与团队合作时可能会成为障碍。
答案 0 :(得分:13)
我在博客文章中描述了一些可能的缺点:http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html
答案 1 :(得分:5)
我遇到DI的问题与我在COM中遇到的问题相同,而且任何代码看起来都像:
i = GetServiceOrInterfaceOrObject(...)
问题在于无法从代码中理解这样的系统。必须有某个文件[else]定义服务/接口/对象X可以请求的服务/接口/对象。该文档不仅必须维护,而且必须像源一样容易获得。
除非文档写得很好,否则通常仍然不容易看到对象之间的关系。有时关系是暂时的,这使得他们更难发现。
我喜欢KISS原则,而且我坚信使用正确的工具来完成工作。如果对于给定项目,DI的好处超过了编写可理解代码的需要,而不是使用它。
答案 2 :(得分:4)
我是IO中的大伙伴但是我看到一些项目包含巨大的xml配置文件,没人理解。所以要注意在xml中编程。
答案 3 :(得分:4)
另外,如果是的话,我会感觉好多了 我正在使用的语言的一部分。
仅供参考,作为JDK 6的一部分,有一个非常简单和功能性的依赖注入。如果你需要轻量级,直接的依赖注入,那么就使用它。
使用ServiceLoader类,您可以根据类请求服务(或许多服务实现):
package dependecyinjection;
import java.util.ServiceLoader;
public abstract class FooService {
public static FooService getService() {
ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);
for (FooService service : loader) {
return provider;
}
throw new Exception ("No service");
}
public abstract int fooOperation();
}
package dependecyinjection;
public class FooImpl extends FooService {
@Override
public int fooOperation() {
return 2;
}
}
ServiceLoader如何定义返回的服务实现?
在项目文件夹中,创建名为 META-INF / services 的文件夹,并创建名为 dependencyinjection.FooService 的文件。此文件包含指向服务实现的行。在这种情况下:dependecyinjection.FooImpl
目前尚未广为人知。
答案 4 :(得分:3)
在我看来,主要的缺点是学习曲线(正如你所指出的)和增加抽象的可能性使调试更加困难(这也是学习曲线的一部分)。
对我来说,DI似乎更适合更大,更复杂的系统 - 对于小型一次性应用程序,它可能导致应用程序过度架构,基本上,让架构需要更多的开发时间来坚持能够弥补其所提供的价值。
答案 5 :(得分:3)
不要再担心了。我认为,随着时间的推移,IoC技术将成为大多数开发人员的第二天性。我正在尝试在这里教导开发人员,我发现很难传达信息,因为我们总是做事情的方式感觉太不自然了......这恰好是错误的方式。此外,IoC新手和我发现的新项目的开发人员都有更难的时间。他们习惯使用IDE来跟踪依赖关系,以了解整个事物如何“挂在一起”。这些信息通常写入神秘的XML。
答案 6 :(得分:2)
你能为我们这些在家里玩的人添加一两个链接来解释实际依赖注入的内容吗? wikipedia article很有趣,但不是很有启发性。
答案 7 :(得分:1)
我能想到的唯一不利因素是通过不断的虚拟调用来降低性能:)
答案 8 :(得分:0)
@Blorgbeard:http://www.martinfowler.com/articles/injection.html可能是有关该主题的最佳文章之一