带有 Reactor mono 的构建器模式
我有火箭课。我想通过构建器实例化一个火箭对象。我需要通过反应性存储库从数据库获取一些状态,但反应性存储库返回 Mono 或 Flux。如何使用 Mono 和 Flux 正确地将状态注入到构建器中。这是我尝试过的。
public class Rocket {
private String engine;
private String fuel;
public Rocket(Builder builder) {
engine = builder.getEngine();
fuel = builder.getFuel();
}
public static class Builder {
private String engine;
protected Mono<String> engineCollector;
private String fuel;
protected Mono<String> fuelCollector;
public Builder() {
}
protected Builder setEngine(Mono<String> engineCollector) {
this.engineCollector = engineCollector.doOnNext((collect) -> {
this.engine = collect;
});
return this;
}
private Builder setFuel(Mono<String> fuelCollector) {
this.fuelCollector = fuelCollector.doOnNext((collect) -> {
this.engine = collect;
});
return this;
}
public String getEngine() {
return this.engine;
}
public String getFuel() {
return this.fuel;
}
public Rocket build() {
return engineCollector
.flatMap(s -> fuelCollector)
.then(Mono.just(new Rocket(this)))
.block();
}
}
}
这种方法是好是坏什么是正确的方法
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
将构建器与响应式 API 结合起来的一种方法如下
:
One way to combine builder with reactive API is the following
where
正如我在评论中所说,尝试将 Mono 转换为非反应式类型的东西与使用反应式编程一开始是背道而驰的。
根据响应式范例,当您拥有
Mono
和Mono
时,您不应该尝试创建Rocket
。您应该创建一个Mono
。现在,代码(注意,出于可读性目的,我将使用实际的名义类型而不仅仅是字符串)。我个人更喜欢 Mono::zip 操作。对于只有两个值的情况,您甚至不需要构建器:
当您确实有两个以上的属性时,这会变得更加复杂,但仍然非常简单。例如,假设您的火箭由三个部分组成:
NoseCone
、Engine
和FuelTank
,而不是两个部分。好吧,Mono::zip
为我们提供了 生成元组的覆盖,具有最多八个:或者,稍微缩短最后几行代码并摆脱丑陋的长类型签名:
As I said, in the comment, trying to convert
Mono
into something that is is not a reactive type kind of flies in the face of using reactive programming to begin with.According to reactive paradigm, you shouldn't try to create
Rocket
when you haveMono<Engine>
andMono<FuelTank>
. You should be creating aMono<Rocket>
, instead.Now, the code (note, that I would use the actual nominal types instead of just strings, for readability purposes). I personally would prefer the Mono::zip operation for most of cases you describe. For the case of just two values, you would not even need the builder:
When you do have more than two properties, this becomes a little more involved, but still pretty straigntforward. For example, consider that your rocket has three parts:
NoseCone
,Engine
, andFuelTank
, instead of two. Well, theMono::zip
has us covered with overrides that produce tuples, having arity of up to eight:Or, to shorten the last few lines of code a little bit and get rid of ugly long type signatures: