Question

我们正在努力建立SOA企业......

考虑更新会员详细信息的三个选项，我们如何设计合同？

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

详情如下：

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

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

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

只能创建和管理一项服务。
如果业务规则增长，这项服务可能会变得不那么紧密。
是否必须区分指定应删除的内容与将其保留原样。
单一工作单元，单笔交易。

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

潜在地简化了单一操作 - 在四个操作中分散了复杂性。
仍然存在必须区分指定应删除某些内容而不是原样保留的问题。例如，如果我只想指定没有婚姻状况的吸烟者身份，该怎么办？
需要深入分析才能弄清楚如何正确分组 - 凝聚力取决于业务流程。
更多写作和维护服务。
交易成为一个问题 - 来电者处理多个交易？

选项3： 分解为更小的静止：Member.UpdateAddress; Member.UpdateBusinessDetails; Member.UpdateContactNumbers; Member.UpdateContactPerson; Member.UpdateEmailAddress; Member.UpdateMailingAddress; Member.UpdatePhysicalAddress;等

消除了必须区分指定应删除某些内容而不是原样保留的问题。
无论何种操作，业务规则都可以轻松发展。
负责编写和维护的服务。
交易成为一个问题 - 许多交易由来电者处理？
开始看起来像属性设置者/ CRUD - 显然是不行。

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

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

Answer 1

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

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

第二个优点是你无法回答“如何一次添加多个地址”的问题 - 因为你不必推断有人从变异的DTO中添加了一个地址，你得到{{1消息。

第三个优势是你可以在一天结束时进行更有趣的业务分析 - 因为你知道发生的事件是什么，而不必分析DTO并推断它。

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

使用“获取数据，改变数据，保存数据”的模型是更少的代码行，但最终会让人更难理解为什么在系统中完成任务 - 这最终会花费你。 / p>

Answer 2

使用带有细粒度参数的粗粒度api。如果您不想更新字段，请传递描述符以及数据。类似的东西：

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

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

如果有人写道：

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

他们很可能只是通过网络进行了3次旅行以及b）3次访问数据库，最后是c）数据库中的3次交易。这并不包括所有涉及的编组和解组乐趣。

当然，这是疯了。

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

因此。粗API，细粒度参数。详细了解您想要做的事情，并一次完成所有工作。

Answer 3

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

＆＃39;直观＆＃39;可能是更好的词在这里 - 对你感觉怎么样？

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

然而，我不喜欢这种想法只有具有UpdateMember功能，然后留下你不想改变空白的字段。我不认为很多人使用这种模式，我当然不会。如你所说，然后如何将字段设置为null。

SOA更新请求粒度和空值

3 个答案: