客户端或服务中的WCF TransactionScope

本文关键字：WCF TransactionScope 服务 客户端 | 更新日期: 2023-09-27 18:28:11

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

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

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

你认为一个好的设计选择是什么？你们认为处理客户的交易是"糟糕的"吗？为此创造一种新方法值得吗？

客户端或服务中的WCF TransactionScope

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

将这两个作为输入

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

  1. 需要付出的努力

    • 修改服务契约类（OperationContract和ServiceBehavior）以支持事务
    • 修饰现有方法（OperationBehavior）以支持事务
    • 修改binding配置
    • 重新配置客户端binding配置

  2. PROS（声称是）：

    • 需要更少的努力=>如第1点所述。在我看来，除非一切就绪，否则很难说这种方法需要更少的精力来实施

  3. CONS：

    • 由于应用程序代码（MVC）和服务代码（WCF）都由您完全控制，因此您可以确保在插入/更新Person和Unit时始终使用事务。然而，我更愿意将其作为black-box服务，这样我就可以将其暴露给其他第三方客户端，或者将该服务交给另一位开发人员使用，而不用担心数据不一致（如果他们忘记/故意跳过事务会怎样？）。尽管您可以强制客户端在调用web服务时始终使用事务（通过使用TransactionFlowOption.Mandatory选项），但我认为良好的做法是只为客户端使用公开最低限度的服务

    • 单一责任也是关注的另一个问题

    • 重复代码（每次要插入Person&Unit时，都需要反复复制代码）

希望有帮助，

抱歉英语不好

相关文章：