如何使用Dagger创建自定义范围?
有指导方针吗?我没找到他们。
我正在开发一个Vaadin应用程序,需要一个自定义范围。像UiScoped这样的东西。
最好的问候
答案 0 :(得分:29)
Dagger没有使用与Guice相同的机制来做范围。具体而言,Dagger并不像Guice那样透明地处理范围,具有各种范围注释,一个Injector和幕后不同的实例缓存。相反,它使用两个原则。首先,@ Singleton的意思是“每个图形一个”(对JSR-330的最严格解释),其次,图形可以在层次结构中链接。
Dagger使用这个分层链接图形树,通过添加更多模块并通过plus()方法扩展它来创建图形,以创建一个寿命更短的“范围”图形。这类似于guice中的Child Injectors。这里的一个重要原则是扩展图中的实例可以看到原始图中的实例,但不能反过来。因此,较短生命周期的同心特性反映在可见性中 - 较短寿命的对象可以看到(依赖于)较长寿命的对象,但不能反过来。因此,在请求的生命周期中生存的对象可以看到一个在应用程序的生命周期中存在的对象,但不是相反的。
通过这种机制,人们期望更狭隘地对缓存实例进行范围调整。
如果用一些模块配置一个图形,并且有一个单例,它将在该图形中缓存一个实例,提供给所有依赖对象。如果通过plus()方法创建该图的扩展,使用包含@Singleton注释绑定的其他模块对其进行配置,那么这些其他模块将是每个图形一个...但是每个模块的一个实例 - 住了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的共享实例,但任何两个请求中的端点都将获得两个不同的RequestObject。
这是一个有点愚蠢的例子,建立在J2EE模式的顶端。这个微不足道的东西,你不会这样构造,你需要更强大的脚手架,以适当的服务器模型。实际上,Dagger项目可能会做这样的事情(尽管我恭敬地建议使用注入的服务对象和单个调度servlet或过滤器)。
但它有望在熟悉的模型中说明一个较窄的范围
键不在注释中,而是在图的生命周期中。您可以创建一个寿命较短的图形作为较长寿命图形的“子”或“扩展”。这些图中记忆的对象具有图管理对象的生命周期(或范围)。