Java 不了解使用依赖注入框架的好处

这是一个诚实的问题，因为我已经开始为我正在从事的一个java项目熟悉Dagger。我目前有这样的设置：我有一个管理器类，它接受请求，利用dao执行事务，然后响应调用者。这是我实现的基本代码：

public class MyManager {
   public Response start(Request req){
      return getDao().save(req);
   }

   public MyDao getDao() {
      return new MyDao();
   }
}

// Clients would then invoke:
// new MyManager().start(req)

现在，如果我理解正确，我将不得不引入一个新的接口和模块来过渡到dagger。该组件看起来像：

@Component(module = MyManagerModule.class)
public interface MyManagerComponent {
   MyManger getMyManager();
}

@Module
public class MyManagerModule {
   @Provides
   public MyDao provideMyDao() {
      return new MyDao();
   }
}

这个模块看起来像：

@Component(module = MyManagerModule.class)
public interface MyManagerComponent {
   MyManger getMyManager();
}

@Module
public class MyManagerModule {
   @Provides
   public MyDao provideMyDao() {
      return new MyDao();
   }
}

最后，我将修改我的原始类，使其具有构造函数注入：

public class MyManager {
   @Getter
   private MyDao dao;

   @Inject
   public MyManager(MyDao dao) {
      this.dao = dao;
   }

   public Resonse start(Request req) {
      return getDao().save(req);
   }
}

// Clients now have to do:
// MyManagerComponent component = DaggerMyManagerComponent.create();
// component.getMyManager().start(req);

对于DI，这似乎要复杂得多。我不仅必须创建模块和接口，而且我的客户机还必须创建一个奇怪的组件，然后从中调用我的管理器。我看不出这有什么好处。我一直听说这有助于单元测试，但我不明白。以前，我只需模拟

getDao（）

方法，就可以轻松地对代码进行单元测试；差不多

manager = Spy(MyManager)
manager.getDao() >> { return Mock(MyDao); }

---

我真的不需要DI来做这件事。这个示例是否太小，无法充分理解DI的好处？

您的代码的上下文是什么？这是一个web应用程序吗？至少对我来说，Dagger似乎不是一个流行的DI框架，所以对于其他人来说，可能需要一些代码的上下文。对于java web应用程序开发，使用“Spring方式”或“java EE方式”，DI将提供很多好处，但这只是使用Spring和JavaEE方式的结果。管理器由AWS Lambda应用程序调用。我不确定Dagger的流行程度，它只是一个被其他人大力推荐的框架，“依赖注入”实际上比人们从中理解的要简单得多<代码>公共MyManager（MyDao）是

DI

。Dao是通过构造函数注入的，例如，它没有声明为

私有静态final…

。当

MyDao

是一个接口时，它甚至更好，您可以插入任何您想要的实现。好处很多，但对我来说，测试是主要的。当

MyDao

可以被模仿时，测试

MyManager

是轻而易举的事。此外，例如，Spring可以在这种设置中做很多很棒的事情。