【问题标题】:Entities and Value Objects in Web ApplicationsWeb 应用程序中的实体和值对象
【发布时间】:2010-09-09 11:45:20
【问题描述】:

我们有一个简单的域模型:Contact、TelephoneNumber 和 ContactRepository。联系人是实体,它有一个身份字段。 TelephoneNumber 是典型的值对象:没有任何标识,不能与 Contact 实例分开加载。

另一方面,我们有用于操作联系人的 Web 应用程序。第一页是“ContactList”,下一页是“Contact/C0001”,显示联系方式和电话号码列表。

我们必须实施电话号码编辑表单。第一个近似的想法是添加一些可导航的页面,如“ThelephoneNumber/T0001”。

但 ThelephoneNumber 是 Value Object 类,无法通过这种方式识别其实例。

解决此问题的最佳做法是什么?我们如何识别无状态应用程序中的不可识别对象?

【问题讨论】:

    标签: architecture web-applications domain-driven-design


    【解决方案1】:

    值对象状态是否标识了该特定实例?如果不是,您可以在提交编辑表单时传回旧值和新值,然后将任何具有旧状态的对象更新为新状态。

    我宁愿有一个像 Contact/C0001/ThelephoneNumber 这样的页面,并使用联系人 id 和值对象类来标识您要更改的实例。

    除非我完全误解了你的要求。

    【讨论】:

    • 嗯,联系人包含许多电话号码。我需要用于编辑其中 1 个数字的表格。我在这里只看到一种方法:使用像 Contact/C0001/ThelephoneNumber/21 这样的 URL,其中 21 是 Contact #0001 中电话号码的 FixedOrderList 类型中的索引。但我不喜欢这个主意
    • 好吧,如果识别该数字实例的唯一方法是通过其状态,那么您将不得不使用上面概述的旧/新状态方法。尽管如果不止一次的联系人可以共享一个电话号码,这将是不可能的。我会考虑让它们成为实体。
    【解决方案2】:

    我会让 TelephoneNumber 只包含一堆数字(可能是复数),然后这样引用它:Contact/C0001/TelephoneNumber(s)

    【讨论】:

      【解决方案3】:

      在实践中,我总是发现给电话号码一个身份更容易,即使这在设计方面并不是绝对必要的。

      如果它是一个严格的值对象,不能存在于联系人上下文之外,这表明一个好的用户界面可能会要求在联系人页面而不是在其自己的页面上编辑电话号码。

      但是,如果您决定反对这两种方法中的任何一种,我认为 Marc Gear 的解决方案是一个很好的解决方案。

      【讨论】:

        【解决方案4】:

        尽管很多人希望你相信什么,但你不可能是 100% 纯洁的。

        您的值对象需要某种身份字段。有时它对于像电话号码这样的对象来说是独一无二的,有时它必须是人造的,比如 TelephoneNumber.Id。

        你越早接受,对你越好:-)

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2011-03-19
          • 1970-01-01
          • 1970-01-01
          • 2010-12-02
          • 1970-01-01
          • 2019-04-03
          • 1970-01-01
          • 2013-01-22
          相关资源
          最近更新 更多