【问题标题】:Few confusing things about passing references to non-root entities to external objects关于将非根实体的引用传递给外部对象的一些令人困惑的事情
【发布时间】:2013-01-23 17:50:02
【问题描述】:

根实体可以将对内部实体的瞬时引用传递给外部对象,但条件是外部对象 操作完成后不要保留该引用

1)

a) 为什么 external object 在单个操作期间具有引用(对 internal entity )是可以接受的,但不能接受它持有在两次操作的持续时间内参考该参考?我的观点是,如果在两次操作期间坚持参考是不好的,那么在一次操作期间坚持参考可能同样不好?!

b) 假设SomeRootEnt 聚合根内部实体的瞬态引用 SomeIntEnt 传递给外部对象,应该如何外部对象 请求SomeIntEnt?通过在 root 上调用特定方法——例如SomeRootEnt.BorrowMeIntEnt(...) - 还是应该 root 直接将 internal entity 暴露为它的 property (例如 SomeRootEnt.SomeIntEnt )?

2)

a) 假设 SomeRootEnt root 将对 internal entity SomeIntEnt 的引用传递给 external object,而后者又进行了一些修改在SomeIntEnt 上,这是否意味着 root 无法对这些修改应用适当的不变逻辑(即 root 可以'不检查修改后的SomeIntEnt的完整性?

b) 同样,至少据我了解,root 也无法强制 外部对象 删除对内部实体的引用> 单次手术完成后?

谢谢

更新:

2a)

没错,这就是为什么最好确保通过 object 没有被修改,而是以不可变的方式使用。此外, 通过的实体仍然可以自行保持一定程度的完整性。

主要是聚合根(部分由传递的实体)还是外部对象(接收transient reference ) 以确保传递的 entity 不被修改?如果是后者,那么这个聚合的一致性真的不是由开发外部对象的人摆布吗?

2b)

正确,您有责任确保这一点。就像你一样 必须确保给定值对象是不可变的(如果需要) 必须考虑传递引用的完整性。

我认为在大多数情况下,外部对象有责任在操作完成后立即摆脱引用?

【问题讨论】:

    标签: domain-driven-design


    【解决方案1】:

    1a) 可能需要对实体的引用来支持域操作,但是该引用应该是暂时的,因为它不会在操作之后保留。它只在操作期间保持,而不是在它之后,因此它不能通过归纳得出它可以保持两个操作。这样做的目的是确保将引用传递给外部实体的聚合可以保持对其成分的控制。您不希望其内部实体被其他聚合接管,因为这样就更难以推理行为。

    1b) 它可以采用任何一种方式,具体取决于用例。属性只是变相的方法。

    2a) 这是正确的,这就是为什么最好确保传递的对象不被修改,而是以不可变的方式使用。此外,通过的实体仍然可以自行保持一定程度的完整性。

    2b) 正确,您有责任确保这一点。就像您必须确保给定值对象是不可变的(如果需要),您必须考虑传递引用的完整性。

    其中大部分是一般准则,因为它会产生“行为良好”、易于推理且易于进行一致的聚合。

    更新

    2a) 考虑到编程语言的局限性,聚合保护自身的能力是有限的。因此,需要“人工干预”,尤其是在像这样的更复杂的场景中。确实,总量可能会受制于他人,这就是制定这些准则的原因。

    2b) 是的。外部对象可以使用另一个聚合的内部实体,但是它的引用应该是瞬态的——这意味着它不会被持久化。

    【讨论】:

    • 呃,我似乎错误地更新了你的帖子 - 抱歉
    【解决方案2】:

    如果具有私有实体的对象获得锁,则将该实体的引用传递给外部方法,该方法永远不允许将其复制到在该方法离开范围后仍然存在的任何位置,然后释放锁,可以肯定当锁被释放时,没有外部实体会持有引用。即使锁中某处的代码抛出异常,该不变量仍将成立。如果允许外部方法将对实体的引用存储在可能超过它的任何地方,即使它承诺某些其他操作将破坏该引用,要确保销毁外部引用所需的操作实际发生也会变得更加困难在锁被释放之前。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-04-13
      • 2013-11-08
      • 2014-11-02
      • 1970-01-01
      相关资源
      最近更新 更多