如何使用 Dagger 创建自定义范围?
有指导方针吗?我没有找到他们。
我正在开发一个 Vaadin 应用程序,并且需要一个自定义范围。像 UiScoped 之类的东西。
此致
如何使用 Dagger 创建自定义范围?
有指导方针吗?我没有找到他们。
我正在开发一个 Vaadin 应用程序,并且需要一个自定义范围。像 UiScoped 之类的东西。
此致
Dagger 没有使用与 Guice 相同的机制来做范围。具体来说,Dagger 并没有像 Guice 那样透明地处理范围,在后台使用各种范围注释、一个 Injector 和不同的实例缓存。相反,它使用两个原则。首先,@Singleton 的意思是“每个图一个”(JSR-330 的最严格解释),其次,图可以在层次结构中链接。
Dagger 使用这种分层链接图树,您可以在其中通过添加更多模块并通过 plus() 方法扩展它来创建一个图,以创建一个生命周期较短的“范围”图。这类似于 guice 中的儿童注射器。这里的一个重要原则是扩展图中的实例可以看到原始图中的实例,但不能反过来。因此,较短寿命的同心特性反映在可见性中 - 寿命较短的物体可以看到(依赖于)寿命较长的物体,但不能相反。因此,在请求的生命周期中存在的对象可以看到在应用程序的生命周期中存在的对象,但反之则不行。
正是通过这种机制,人们有望更窄地确定缓存实例的范围。
如果一个人用一些模块配置了一个图,并且有一个单例,它将在该图中缓存一个实例,提供给所有依赖对象。如果通过 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 或过滤器)。
但它希望在一个熟悉的模型中说明一个更窄的范围
关键不在注释中,而在图的生命周期中。您创建一个寿命较短的图表作为一个寿命较长的图表的“子”或“扩展”。这些图中记忆的对象具有图管理对象的生命周期(或范围)。