c# - 如何组织和命名在 WCF Web 服务中用作数据协定的 DTO

Question

我们在 WCF 网络服务中使用 DTO 作为数据契约。这些 DTO 的目的是仅公开与特定 API 方法相关的信息。

我想从你们那里寻求一些关于最佳实践的建议。

例如，考虑以下简单模型:

class Order
{
    int CreatedBy { get; set; }
    DateTime CreatedOn { get; set; }
    string Description { get; set; }
    int Id { get; set; }
    string Name { get; set; }
}

假设我们的 API 允许消费者创建、更新 和获取 订单，我们创建了以下 DTO。为简单起见，删除了 DataMember 和 DataContract 属性。

Create 方法:用户无法指定 Id 和 CreatedOn 属性，因此 DTO 如下所示:

class CreateOrderData
{
    int CreatedBy { get; set; }
    string Description { get; set; }
    string Name { get; set; }
}

Update 方法:用户无法指定 Id、CreatedOn 和 CreatedBy 属性，因此 DTO 看起来像这样:

class UpdateOrderData
{
    string Description { get; set; }
    string Name { get; set; }
}

Get 方法:用户应该能够看到订单的所有内容，因此 DTO 如下所示:

class OrderData
{
    int CreatedBy { get; set; }
    DateTime CreatedOn { get; set; }
    string Description { get; set; }
    int Id { get; set; }
    string Name { get; set; }
}

所以这是我的问题:

• 假设 Order 模型中有更多属性，并且其中许多属性在“创建”和“更新”DTO 之间共享，那么让这些类从公共(public)基类扩展是否有意义？如果是，“获取”DTO (OrderData) 是否也应该从该类扩展？如果我们这样做，是否会让这些 DTO 过于依赖彼此？

• 如果“创建”和“更新”DTO 的所有属性都是通用的，我们是否仍应创建两个不同的 DTO？如果是，为什么？如果不是，(现在这只是一个命名问题)“CreateOrUpdate”DTO应该叫什么，这样名字就明显不同于“Get”DTO？

• 可以为所有 DTO 加上诸如“Data”、“DataObject”或“Dto”之类的后缀吗？

• 我们走在正确的轨道上吗？如果不是，如何让这个设计变得更好？

更新:

我认为我不喜欢 DTO 中的继承，因为基类也将在 WSDL 中公开，客户端将能够看到它并实例化它，这对我来说似乎很脏(参见:WCF Serialization with object inheritance?) .如何在 DTO 中使用接口(interface)来强制执行公共(public)属性而不是继承？由于 DTO 中不应该有任何行为，因此我们通过替换继承不会损失太多。

Answer 1

由于这与个人喜好有很大关系，所以我会这样做..

1. 我不会创建通用基类，因为它不符合 SOLID 中的 L。如果您担心 DRY，那么您可以改为创建聚合。

2. 如果所有属性都是通用的，那么创建一个接受该对象的 Save 才有意义，订单 Dto 类将具有一个关键属性，该属性将指示其是否为现有订单。

3. 我会用 Dto 作为后缀，因为很多 Dto 类名与域类相同，它们会混淆，因为它们将一起存在于同一个方法中。然后你可以用 DataContract(Name="Order", Namespace="htp://yourdomain/..") 装饰你的 Dtos。这样他们就会根据你自己的喜好暴露给外界。

   <

我参与过多个使用相同通用架构的项目，我通常使用 AutoMapper 将 dto 映射到域。它对我很有用!