客户端或服务中的WCF TransactionScope

Question

假设我需要调用多个服务，这些服务在同一个事务中使用EF插入一些记录，用于插入Person和Unit。

我不确定是否应该创建一个名为AddPersonAndUnit的新操作合同并在该方法中使用TransactionScope并从客户端调用它或者不创建任何其他方法并且只使用{客户端（ASP.NET MVC客户端）中的{1}}并调用已存在的TransactionScope和AddPerson。

对于单一责任并将所有业务逻辑移动到服务层，我认为在服务层中定义一个额外的方法并从客户端调用它似乎是一个更好的选择，但另一方面，从客户端调用这些多个方法需要更少的工作量

您如何看待良好的设计选择？你认为处理客户交易是“坏”吗？是否值得为此创建一个新方法？

Answer 1

根据您的问题，您有两个项目（ASP.NET MVC＆amp; WCF），并且您希望确保Person和Unit < strong>以事务方式插入/更新

将这两项作为投入

让我们快速分析选项1（在客户端代码中使用TransactionScope（代理类））

1. 需要的努力

   • 修改服务合同类（OperationContract和ServiceBehavior）以支持交易
   • 解析现有方法（OperationBehavior）以支持交易
   • 修改binding config
   • 重新配置客户端binding配置

2. PROS（索赔）：

   • 需要较少的努力=＆gt;如点 1 中所述，在我看来，很难说这种方法需要较少的工作量，除非一切都已到位

3. <强> CONS ：

   • 由于应用程序代码（MVC）和服务代码（WCF）都被完全控制，因此您可以确保始终使用插入/更新Person和Unit时的交易。但是，我更愿意将其作为black-box服务，以便我可以将其公开给其他第三方客户端或将服务提供给其他开发人员使用而不用担心数据不一致（如果他们忘了/故意跳过交易？）。即使您可以强制客户端在调用Web服务时始终使用事务（通过使用TransactionFlowOption.Mandatory选项），我认为良好做法只是为客户端提供最少的服务

   • 单一责任也是另一个问题

   • 重复代码（每次要插入Person＆amp; Unit时，您需要反复复制代码）

希望它有所帮助，

抱歉英文不好