java - Dagger 自定义范围，如何？

Question

如何使用 Dagger 创建自定义作用域？

有指导方针吗？我没有找到它们。

我正在开发一个 Vaadin 应用程序，需要一个自定义范围。类似 UiScoped 的东西。

最好的问候

Answer 1

Dagger 不使用与 Guice 相同的机制来处理作用域。具体来说，Dagger 不像 Guice 那样透明地处理作用域，在幕后使用各种作用域注释、一个注入(inject)器和不同的实例缓存。相反，它使用两个原则。首先，@Singleton 的意思是“每个图一个”(JSR-330 的最严格解释)，其次，图可以在层次结构中链接。

Dagger 使用这种分层链接图树，您可以通过添加更多模块并通过 plus() 方法扩展它来创建图，以创建一个生命周期较短的“范围”图。这类似于 guice 中的 child 注入(inject)器。这里的一个重要原则是扩展图中的实例可以看到原始图中的实例，但反之则不行。因此，较短生命周期的同心性质反射(reflect)在可见性中——较短生命周期的物体可以看到(依赖于)较长生命周期的物体，但反之则不行。因此，在请求的生命周期内存在的对象可以看到在应用程序的生命周期内存在的对象，但反之则不行。

正是通过这种机制，人们才有望缩小缓存实例的范围。

如果用一些模块配置一个图形，并且有一个单例，它将在该图形中缓存一个实例，提供给所有依赖对象。如果通过 plus() 方法创建对该图的扩展，并使用包含 @Singleton 注释绑定(bind)的其他模块对其进行配置，那么这些其他模块将是每个图一个......但每个实例一个较短的 -存在的 ObjectGraph 实例。

例如，让我们模拟一个响应请求的服务器，我们想要一些对象在应用程序的生命周期内存在，而一些对象只在请求的较短生命周期内存在:

@Module()
public class MyAppModule {
  @Provides ConnectionDictonary connectionDictionary() {
    return new ConnectionDictonary(System.getProperty("some.property"));
  }

  /** Stateless mockable utilities for this app */
  @Provides Util util() { new Util(); }

  @Provides @Singleton DataStore store() { 
    return new DataStore();
  }

  @Provides @Singleton ConnectionPool pool(DataStore store, ConnectionDictionary dict) { 
    try {
      return DataStore.connectionPool(dict, System.getProperty("pool.size"));
    } catch (Exception e) {
      // bad bad bad
      throw new RuntimeException("Could not connect to datastore.", e);
    }
  }

}

// This module "adds to" MyAppModule by adding additional graph elements in
// an extended graph.
@Module(injects=MyRequestEndpoint.class, addsTo = MyAppModule.class)
public class MyRequestModule {
  private Request req;
  public MyRequestModule(Request req) { this.req = req; }

  @Provides @Singleton RequestObject request() { return req; }

  @Provides @Singleton User user(ConnectionPool pool, Request req, Util util) {
    try {
      Connection conn = pool.obtain();
      // getUser cannot throw null;
      return util.getUser(conn, req.get("user.id"), Crypto.hash(req.get("pass")));
    } catch (UserNotFoundException e) {
      return User.UNKNOWN;
    } catch (Exception e) {
      throw new RuntimeException("Could not obtain a user.", e);
    } finally { 
      // TODO: try-with-resources in Java7
      pool.release();
    }
  }

}

public class MyRequestEndpoint {
  @Inject ConnectionPool pool;
  @Inject Request req;

  public Output performService() {
    try {
      Connection conn = pool.obtain();
      // ... does stuff with request
    } finally {
      conn.release();
    }
  }
}

public class MyApp {    
  public void main(String ... args) {
    graph = ObjectGraph.create(MyAppModule.class);
    new ServiceListener(graph).start(); 
  }
}

public ServiceListener {
  private final ObjectGraph appGraph;
  public ServiceListener(ObjectGraph appGraph) {
    this.appGraph = appGraph;
  }

  //... infrastructure for listening and building request/response objects, etc.

  public void serveRequest(Request req, Response res) {
    // Take the application-scoped graph and create another graph we will 
    // use in this request and throw away.
    ObjectGraph requestGraph = MyApp.graph().plus(new MyRequestModule(req));
    Output output = requestGraph.get(MyRequestEndpoint.class).performService();
    Util.populateResult(output, result);
    result.flush();
  }
}

在此示例中，每个 MyRequestEndpoint 将获得一个共享的 ConnectionPool 实例，但任何两个请求中的一个端点将获得两个不同的 RequestObjects。

这是一个有点愚蠢的例子，它是在我脑海中根据 J2EE 模式构建的。您不会以这种方式构造这种微不足道的东西，并且您需要更强大的脚手架来构建适当的服务器模型。事实上，Dagger 项目可能会做这样的事情(尽管我恭敬地建议使用注入(inject)的服务对象和单个调度 servlet 或过滤器)。

但它有望在熟悉的模型中说明更窄的范围

关键不在注释中，而在图的生命周期中。您创建一个生命周期较短的图形作为生命周期较长图形的“子”或“扩展”。这些图中存储的对象具有图管理对象的生命周期(或范围)。