如何正确处理具有深层对象图和许多依赖项的手动DI [英] How to do manual DI with deep object graphs and many dependencies properly

问题描述

我相信已经以某种方式提出了这个问题，但我还没有得到解决。

我们进行了GWT项目，但项目负责人不允许将GIN / Guice用作DI框架（他认为，新的程序员不会理解它），所以我尝试手动进行DI。

现在，我有一个深对象图的问题。 UI中的对象层次结构如下所示：

AppPresenter-> DashboardPresenter-> GadgetPresenter-> GadgetConfigPresenter

GadgetConfigPresenter在对象层次结构树的下方有一些依赖性，例如CustomerRepository，ProjectRepository，MandatorRepository等。 ，直到创建AppPresenter的应用的入口点。

• 这是手动DI应该起作用的方式吗？


• 这不是意味着我即使不需要也可以在启动时创建所有依赖项吗？


• 像GIN / Guice这样的DI框架对我有帮助吗？在这里？

解决方案

您写的是

创建GadgetConfigPresenter [。]的GadgetPresenter [。]

代替直接创建 GadgetConfigPresent er 实例， GadgetPresenter 应该依赖可以创建 GadgetConfigPresenter的抽象工厂 实例。这会将 GadgetConfigPresenter 的内部依赖关系推送到工厂。

使用构造函数注入全部这样，您的穷人的DI 接线应该看起来像这样（对C＃语法表示歉意）：

  var customerRepository =新的CustomerRepository（/*...*/）; 
 var projectRepository = new ProjectRepository（/*...*/）; 
 var mandatorRepository = new MandatorRepository（/*...*/）; 
 
 var gadgetConfigPresenterFactory = 
新的GadgetConfigPresenterFactory（
 customerRepository，
 projectRepository，
 mandatorRepository）; 
 
 var gadgetPresenter =新的GadgetPresenter（gadgetConfigPresenterFactory）; 
 var consolePresenter =新的DashboardPresenter（gadgetPresenter）; 
 var appPresenter =新的AppPresenter（dashboardPresenter）; 
  

注意我们经常打破依赖链的方式，确保数量每个消费者的依赖关系永远不会变得太大。

原则上，这意味着您必须在启动时创建所有依赖关系，除非您实现延迟加载策略。

如此管理生命周期之类的事情正是DI容器可以提供极大帮助的事情，但是完全可以通过遵循DI模式和原理。

总而言之，我仍然建议使用DI容器

I believe this questions has been asked in some or the other way but i'm not getting it yet.

We do a GWT project and my project leader disallowed to use GIN/Guice as an DI framework (new programmers are not going to understand it, he argued) so I try to do the DI manually.

Now I have a problem with deep object graphs. The object hierarchy from the UI looks like this:

AppPresenter->DashboardPresenter->GadgetPresenter->GadgetConfigPresenter

The GadgetConfigPresenter way down the object hierarchy tree has a few dependencies like CustomerRepository, ProjectRepository, MandatorRepository, etc.

So the GadgetPresenter which creates the GadgetConfigPresenter also has these dependencies and so on, up to the entry point of the app which creates the AppPresenter.

• Is this the way manual DI is supposed to work?
• doesn't this mean that I create all dependencies at boot time even I don't need them?
• would a DI framework like GIN/Guice help me here?

解决方案

You write that

the GadgetPresenter which creates the GadgetConfigPresenter[.]

Instead of directly creating GadgetConfigPresenter instances, GadgetPresenter should take a dependency on an Abstract Factory that can create GadgetConfigPresenter instances for it. This pushes the inner dependencies of GadgetConfigPresenter to the factory.

Using Constructor Injection all the way, your Poor Man's DI wiring should look something like this (apologies for the C# syntax):

var customerRepository = new CustomerRepository(/*...*/);
var projectRepository = new ProjectRepository(/*...*/);
var mandatorRepository = new MandatorRepository(/*...*/);

var gadgetConfigPresenterFactory = 
    new GadgetConfigPresenterFactory(
        customerRepository,
        projectRepository,
        mandatorRepository);

var gadgetPresenter = new GadgetPresenter(gadgetConfigPresenterFactory);
var dashboardPresenter = new DashboardPresenter(gadgetPresenter);
var appPresenter = new AppPresenter(dashboardPresenter);

Notice how we break the dependency chain often, ensuring that the number of dependencies for each consumer never becomes too big.

In principle, this means that you must create all the dependencies at boot time, unless you implement a lazy loading strategy.

Such things as managing lifetimes are exactly the sort of thing where a DI Container can be enormously helpful, but it's entirely possible to write an entire application by just following DI patterns and principles.

All in all, though, I would still recommend a DI Container if at all possible.

这篇关于如何正确处理具有深层对象图和许多依赖项的手动DI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！