2

我们正在努力成为 SOA 企业……

给定更新成员详细信息的三个选项，我们如何设计合同？

业务流程非常简单。客户致电（或自己登录）并更新他们的个人详细信息，以便我们获得最新的详细信息。客户雇主还可以提供成员详细信息（这将是批量的 - 一次可能是 1000 个）。这样我们就可以在未来与他们正确沟通。我们有多个后端系统。

详情如下：

  • 电话号码，
  • 地址，
  • 电子邮件，
  • 姓名或公司名称，
  • 联系人，
  • 税号，
  • 婚姻状况
  • 吸烟者身份

就目前而言，业务规则是： 如果已经提供了有效的税号，则不能再次提供。（可以覆盖）如果存在有效的地址详细信息，雇主无法更新它们，只能在第一次提供。

选项 1： 一项操作，Member.UpdateDetails

  • 只需创建和管理一项服务。
  • 如果业务规则增长，这项服务的凝聚力可能会降低。
  • 有必须区分指定应该删除的东西和保持原样的问题。
  • 单一工作单元，单一事务。

选项2： 分解为四个操作：Member.UpdateContactDetails；Member.ProvideTaxFileNumber; 成员.UpdateName; Member.UpdateDemographics

  • 潜在地简化了单个操作 - 将复杂性分散到四个操作中。
  • 仍然存在必须区分指定应删除某些内容与保持原样的问题。例如，如果我只想指定吸烟者身份而不指定婚姻状况怎么办。
  • 需要一些深入的分析来弄清楚如何正确地对它们进行分组——凝聚力取决于业务流程。
  • 编写和维护更多服务。
  • 事务成为一个问题 - 调用者处理多个事务？

选项3： 分解成更小的仍然：Member.UpdateAddress；Member.UpdateBusinessDetails; Member.UpdateContactNumbers; Member.UpdateContactPerson；Member.UpdateEmailAddress; Member.UpdateMailingAddress; Member.UpdatePhysicalAddress; 等等

  • 消除了必须区分指定应删除的内容与保持原样的问题。
  • 业务规则可以在任何操作中轻松演变。
  • 需要编写和维护的大量服务。
  • 事务成为一个问题 - 调用者处理了许多事务？
  • 开始看起来像属性设置器/CRUD - 显然不行。

在选项一或二中，假设呼叫者只想更新家庭电子邮件地址 - 我不能指望客户完成整个消息 -客户是否将所有其他标签都排除在外？ 处理这个问题的公认的、明显的、直观的模式是什么？

如果这确实是模式，那么客户端如何清除该字段或将其设置为 null？ 在.NET 中，在服务器代码中，我看不到区分未提供和空值的明显方法。由于这并不明显，我希望这不是一个可接受的模式。

4

3 回答 3

1

我强烈建议第二个选项，因为它保留了用户进行更改的意图，一直到对其起作用的代码。

第一个优点是它免除了您回答“我如何在 DTO 中表示删除”的问题 - 因为现在您可以DeleteContactNumber明确地将该事实作为消息捕获。

第二个优势是您无需回答“我如何一次添加多个地址”的问题 - 因为您不必推断有人从变异的 DTO 添加了地址，您会收到一条AddContactAddress消息。

第三个优势是您可以在一天结束时进行更有趣的业务分析——因为您知道发生的事件是什么，而无需对 DTO 进行分析和推断。

最后，为特定事件添加更多信息变得很容易：您想知道人们为什么要删除他们的联系地址吗？

使用“获取数据、修改数据、保存数据”的模型会减少代码行数，但最终会让人更难理解为什么要在系统中完成这些事情——这最终会让你付出代价。

于 2011-12-06T19:51:37.437 回答
1

使用带有细粒度参数的粗粒度 API。如果您不希望更新字段，请传递一个描述符，说明该描述符与数据一起。就像是：

Result updateMember(Member member, List<String> fieldsToUpdate)

拥有细粒度的 API 基本上是死亡，因为传输通常是模糊的。

如果有人写：

UpdateContactNumbers(...);
UpdateAddress(...);
UpdatePersonalDetails(...);

他们很可能刚刚进行了 a) 3 次网络旅行以及 b) 3 次访问数据库，最后以 c) 数据库上的 3 次交易结束。这还不包括所涉及的所有编组和解组的乐趣。

当然，这很疯狂。

是否需要远程服务 API？不，当然不是，但很多是，并且至少，许多是透明的传输（可能是本地的或远程的，你不知道）。

所以。粗略的 API，细粒度的参数。详细地弄清楚你想做什么，然后一口气做完。

于 2011-12-06T22:55:55.133 回答
0

就个人而言，我认为同时拥有 UpdateMember 功能和 UpdateAddress 等更简单的功能并没有太大的错误。有些人可能会争辩，但我认为这是完全可以接受的。

在这里，“直觉”可能是一个更好的词——你觉得什么是对的？

对我来说，UpdateMember 似乎是一个明确的候选人。如果 UI 正在使用此服务，则所有字段都可能已由 GetMember 调用填充，因此所有字段都将使用其原始值填充。即使它不是 UI，您也可以使用类似的东西。然后，对于更简单、更专业的情况，您也可以使用 UpdateAddress、Update PersonalDetails。

但是，我不喜欢这种想法，即仅具有 UpdateMember 功能，然后将您不想更改的字段留空。我不认为很多人使用这种模式，我当然不会。正如您所说，您如何将字段设置为空。

于 2011-12-06T15:42:19.150 回答