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

有一项服务可与

客户

实体合作

服务已经实现了一个

GetCustomer

方法，该方法返回一个

CustomerDTO

服务必须实施更改客户的

电话

、

地址

、

销售经理

和

折扣

的方法。客户只允许更改

电话

和

地址

，销售总监只允许更改客户的

销售经理

，而销售经理只允许更改客户的

折扣

我是否应该只创建一种服务方法

ChangeCustomer

？

• 我是否应该使用

  CustomerDTO

  作为

  GetCustomer

  方法中的返回类型，例如

  ChangeCustomer（CustomerDTO）

• 我是否应该使用其他

  CustomerChangeDTO

  ，例如

  ChangeCustomer（CustomerChangeDTO）

我是否应该创建几种服务方法

ChangeCustomerPhone

，

ChangeCustomerAddress

，

ChangeCustomerManager

和

ChangeCustomerDiscount

？

• 我是否应该在这些服务方法中使用

  CustomerDTO

  ，例如

  ChangeCustomerName（CustomerDTO）

• 我是否应该在每个服务方法中使用单独的DTO类，例如，

  ChangeCustomerName（CustomerMechanageDTO）

也许还有其他一套服务方法

似乎单个DTO类使服务更易于在客户端上使用，因为客户端所要做的就是请求

CustomerDTO

，更改它的一些属性并发送回。服务是处理

CustomerDTO

中的所有更改，并将业务逻辑应用于real

Customer

实体和其他实体

---

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

您的WCF服务位于应用程序层，因此每个用例都应该有一个单独的方法。这里有3个用例：

客户可以更改

电话

和

地址

销售总监可以更改销售经理

销售经理可以更改

折扣

因此，您的服务应该公开3种方法。这些方法中的每一种不仅必须更新

客户

实体，还必须首先检查权限。如果您尝试用一种方法来实现它，您将得到大量的

If

s和不清楚的行为。例如，如果销售经理试图更改

折扣

和

电话

，该怎么办？忽略

电话

？抛出异常

每个方法都应该使用不同的DTO，只包含该方法所需的属性。（顺便说一句，您可以将类名中的“DTO”更改为“Command”——例如

ChangeCustomerDiscountCommand

。看起来比“DTO”更好）

---

如果您使用一个DTO，客户端会感到困惑（为什么类中有其他属性？如果我将它们保留为空会发生什么？如果我更改它们会发生什么？等等）

嗨，Jakub，他是否需要在域层中使用包含所有属性的完整Customer类？首先从资源访问（CustomerRA->Customer）加载Customer域类，然后在检查安全性后应用必要的更改，然后将完整的Customer类转换为CustomerRA以传递给资源进行保存？