依赖注入成瘾？

就不用担心它的最好的文章之一。我认为，IoC技术对于大多数开发者来说将是第二天性。我正在努力在这里教授开发人员关于它的事情，我发现很难传达信息，因为它对我们一直做事情的方式感觉非常不自然，这恰恰是错误的方式。另外，IoC新手和我发现的新项目的开发人员都遇到了更多困难。他们习惯于使用IDE来追踪依赖关系，以了解整个事物如何“挂在一起”。这些信息通常写入奥术XML。

来源

2008-09-03 22:18:59 tgeros

此外，如果它是我使用的语言的一部分，我觉得它会好很多。

仅供参考如果您需要轻量级，简单的依赖注入，然后使用它，那么在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 /服务文件夹，并创建一个名为dependencyinjection.FooService文件。该文件包含指向服务实现的一行。在这种情况下：依赖注入.FooImpl

这还不是广为人知。

来源

2008-09-03 22:19:07

这种模式不是称为“服务定位器”而是“依赖注入”吗？请参阅http://www.martinfowler.com/articles/injection.html获取两者的描述。 – 2009-04-29 01:49:19

使用这种模式会导致开发人员疯狂时，他们必须为服务隐藏的依赖关系...... – mathieu 2012-07-31 09:55:30

我有DI的问题是同样的问题，我有一个COM，并与看起来像任何代码：

i = GetServiceOrInterfaceOrObject(...)

的问题是，这样的系统不能从代码可以理解。在[else]中必须有文档定义服务/接口/对象X可以请求哪些服务/接口/对象。该文档不但必须保留，而且可以像源代码那样容易地获得。

除非文档写得很好，否则通常很难看到对象之间的关系。有时候，关系是暂时的，这使得他们更难以发现。

我喜欢KISS的原则，我坚信使用正确的工具来完成这项工作。如果给定项目的DI的好处超过编写可理解代码的需要，那么比使用它更好。

来源

2011-02-12 20:23:28 Tergiver

依赖注入成瘾？

回答

相关问题