具有嵌套的聚合对象
我创建了一个名为 DrivingLog 的聚合类。我只在下图中包含了必要的字段。
现在,当我想添加驾驶记录时,我在 DrivingLog
对象上输入 addRecord(Double distance, ...)
。但是,DrivingRecord 是 Condition
和 Environment
类的聚合,还是只是引用?条件和环境在 DrivingRecord
之外没有任何值。
条件和环境是静态数据:用户将在 JSF 视图的下拉列表中的预定义值中进行选择。但如果 DrivingRecord
是一个聚合,它应该有一个名为 addEnviroment()
的方法。这应该以 Enviroment
类作为参数吗?
如果是这种情况,DrivingLog
是否会有一个名为 addRecord(Double distance,Environment 环境...)
的方法?
最后,环境和条件不应该被聚合根“隐藏”并且永远不会从外部访问。这让我思考 DrivingRecord 是否真的也是一个聚合根。
是否允许聚合嵌套,这是不好的做法,在某些情况下可以吗?
I have made an aggregated class named DrivingLog. I have only included the necassary fields in the picture below.
Now, when I want to add a driving record I say addRecord(Double distance, ...)
on the DrivingLog
object. However, is the DrivingRecord an aggregate for the Condition
and Environment
class or are they only references? Condition and Enviroment has no value outside one DrivingRecord
.
Condition and Environment is static data: The user will be selecting among predefined values in a dropdown list in the JSF view. But if the DrivingRecord
is an aggregate it should have a method namedaddEnviroment()
. Should this be taking the Enviroment
class as argument?
If thats the case would the DrivingLog
have a method named addRecord(Double distance, Environment environment...)
?
And last, shouldn't Environment and Condition be "hided" by the aggregate root and never accessed outside. This make me think if the DrivingRecord really is an aggregated root as well.
Is the nesting of aggregates even allowed, bad practice, ok in some cases?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我建议使用
addRecord(DrivingRecord record)
作为服务的 API。我不确定我是否遵循您可能意味着的术语,但我认为这两个答案都是正确的 - DrivingRecord 是一个聚合(我想“指向一堆对象”),但也是一个引用(如任何对象“handel”)在Java中被认为是参考)。
要点是 - 它不是作为 blob 传递,而是作为对堆内存的 4 字节引用传递,如果您使用“new XYZ”实例化它(或堆栈,如果它是作为参数传递给方法的基元)。而且只要它被一个活着的对象引用,它就不会被垃圾收集。
构造 DrivingRecord 实例后,您需要允许插入对 List 的引用。
我不知道这些参数是否彼此相关,但如果它们可以单独添加,我建议这样:
当然
对您的项目目标知之甚少,我无法判断是否有更好的架构。但这当然不是一个坏习惯。
I'd suggest
addRecord(DrivingRecord record)
instead, as an API for your service.I'm not sure I follow the terminology as you might mean, but I think both answers are correct - DrivingRecord is an aggregate (I suppose "pointing to a bunch of objects"), but also a reference (as any object "handel" in Java is considered a references).
The point is - it's not passed around as a blob, but as 4 byte references to the heap memory if you instanciated it with "new XYZ" (or stack, if it's a primitive that is passed as an argument to a method). And it won't be garbage collected as long as it is referenced by a living object.
after constructing an instance of DrivingRecord, you'll need to allow insertion of references to List.
I don't know if the parameters are related to each other, but it they can be added seperately, I'd suggest something like that:
sure
Knowing very little about your project goals I can't tell if there's better architecture. But it's certainly not a bad practice.