Question

我采取了暴跌并将Guice用于我的最新项目。整体印象很好，但我遇到了一个我无法理解的问题。

背景：这是一个Java6应用程序，它通过网络接受命令，解析这些命令，然后使用它们来修改一些内部数据结构。它是我们公司生产的某些硬件的模拟器。我对内部数据结构所做的更改与命令对实际硬件的影响相匹配，因此数据结构的后续查询应该基于先前运行的命令反映硬件状态。

我遇到的问题是命令对象需要访问这些内部数据结构。这些结构由Guice创建，因为它们根据所模拟硬件的实际实例而有所不同。 Guice没有创建命令对象，因为它们本质上是哑对象：它们接受文本字符串，解析它，并在数据结构上调用方法。

我能让这一切工作的唯一方法是让Guice创建这些命令对象，并通过注入传递数据结构。它感觉非常笨重，完全膨胀了数据对象的构造函数。

我在这里错过了什么？

Answer 1

依赖注入最适合布线服务。它可以用来注入值对象，但这可能有点尴尬，特别是如果这些对象是可变的。

也就是说，您可以使用Providers和@Provides方法绑定您自己创建的对象。

Answer 2

假设响应命令与响应http请求没有什么不同，我认为你走的是正确的道路。

http应用程序中常用的模式是将应用程序的逻辑包装成短期对象，这些对象具有来自请求和注入的一些后端的参数。然后你实例化这样的对象并调用一个简单的，无参数的方法来完成所有魔法。

也许范围会以某种方式激励你？查看into documentation和some code examples以了解技术详情。在代码中，它看起来更像是那样。以下是这可能适用于您的情况：

class MyRobot {
   Scope myScope;
   Injector i;       

   public void doCommand(Command c) {
      myScope.seed(Key.get(Command.class), 
      i.getInstance(Handler.class).doSomething();
   }
}


class Handler {
   private final Command c;
   @Inject
   public Handler(Command c, Hardware h) {
     this.c = c;
   }

   public boolean doSomething() {
     h.doCommand(c);
     // or c.modifyState(h) if you want c to access internals of h
   }
}

有些人不赞成这个解决方案，但我在过去至少在两个不同的项目中严重依赖Guice的代码中看到了这一点。

当然，你会在构造函数中注入一些值对象，但是如果你不认为它们是值对象，而是改变它的行为的类的参数，这一切都是有意义的。

有点尴尬，有些人对这种方式注入价值对象不屑一顾，但过去我曾经看过很多依赖Guice一段时间的项目，而且效果很好。

从Guumb数据对象获取Guice创建的对象

2 个答案: