有不好的一面吗?我觉得现在几乎要依赖它了.每当项目超过一定规模时,几乎感觉到对标准模式的过敏反应,并立即用依赖注入框架重新连接它.
我发现的最大问题是,对于刚刚学习它的其他开发人员来说,这可能会令人困惑.
而且,如果它是我使用的语言的一部分,我会感觉好多了.虽然,至少对于Java来说,有一些非常轻量级的库非常好.
思考?糟糕的经历?或者只是不要担心它?
[编辑] Re:依赖注入本身的描述
抱歉模糊不清.Martin Fowler可能比我更好地描述了FAR ......不需要浪费精力.
巧合的是,这证实了有关它的一点,它仍然没有被广泛实践,并且如果每个人都没有达到速度,那么在与团队合作时可能会成为障碍.
我在博客文章中描述了一些可能的缺点:http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html
我在DI中遇到的问题与我在COM中遇到的问题相同,而且任何代码看起来都像:
i = GetServiceOrInterfaceOrObject(...)
问题是从代码中无法理解这样的系统.必须有某个文件[else]定义服务/接口/对象X可以请求哪些服务/接口/对象.该文档不仅必须维护,而且必须像源一样容易获得.
除非文档写得很好,否则通常仍然不容易看到对象之间的关系.有时关系是暂时的,这使得它们更难以发现.
我喜欢KISS原则,我坚信使用正确的工具来完成工作.如果对于给定项目,DI的好处超过了编写可理解代码的需要,而不是使用它.