我应该为每个服务方法创建一个单独的 DTO class 吗？

Question

有一项服务可用于 Customer 实体。

服务已经实施了 GetCustomer 方法，其中 return 是 CustomerDTO。

服务必须实施方法来更改客户的 Phone、Address、SalesManager 和 Discount。客户只能更改 Phone 和 Address，销售总监只能更改客户的 SalesManager，而销售经理只能更改客户的 Discount.

1. 我应该只创建一个服务方法ChangeCustomer吗？
   • 我是否应该使用 CustomerDTO，我在 GetCustomer 方法中用作 return 类型，例如ChangeCustomer(CustomerDTO)?
   • 我应该使用其他一些 CustomerChangeDTO，例如ChangeCustomer(CustomerChangeDTO)?
2. 我是否应该创建多个服务方法 ChangeCustomerPhone、ChangeCustomerAddress、ChangeCustomerManager 和 ChangeCustomerDiscount？
   • 我应该在每个服务方法中使用 CustomerDTO 吗？ ChangeCustomerName(CustomerDTO), ...?
   • 我是否应该在每个服务方法中使用单独的 DTO class，例如ChangeCustomerName(CustomerNameChangeDTO), ...?
3. 也许还有其他一些服务方法？

似乎单个 DTO class 使服务在客户端上更容易使用，因为所有客户端必须做的就是请求 CustomerDTO，更改它的一些属性并发回。服务是处理 CustomerDTO 中的所有更改，并将业务逻辑应用于真实的 Customer 实体和可能的其他实体。

每个变体还有其他优点/缺点吗？

Answer 1

您的 WCF 服务位于应用程序层，因此它应该为每个用例提供一个单独的方法。您在这里显然有 3 个用例：

1. 客户可以更改 Phone 和 Address
2. 销售总监可以更换SalesManager
3. 销售经理可以更改 Discount

因此您的服务应该公开 3 个方法。这些方法中的每一个不仅必须更新 Customer 实体，还必须首先检查权限。如果您尝试用 1 种方法实现它，您最终会遇到很多 if 和不明确的行为。例如，如果销售经理试图更改 Discount 和 Phone，该怎么办？忽略 Phone?抛出异常？

每个方法都应使用不同的 DTO，仅包含该方法所需的属性。 （顺便说一句，您可以将 class 名称中的 'DTO' 更改为 'Command' - 例如 ChangeCustomerDiscountCommand。看起来比 'DTO' 更好）。

如果使用单一的DTO，客户端会感到困惑（为什么class中还有其他属性？如果我将它们留空会怎样？如果我改变它们会怎样？等等）