问如何组织和命名在WCF web服务中用作数据约定的DTO

EN

我们在我们的WCF web服务中使用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; }
}

所以我的问题是：

• 假设订单模型中有更多的属性，并且这些属性在“创建”和“更新”DTO之间共享，那么让这些类从公共基类扩展有意义吗？如果是，"Get“DTO (OrderData)是否也应该从该类扩展？
• 如果“创建”和“更新”DTO的所有属性都是相同的，我们还应该创建两个不同的DTO吗？若有，原因为何？如果不是，(现在这只是一个命名问题)应该如何调用"CreateOrUpdate“DTO，以使其名称明显不同于"Get”Dto？
• 是否可以在所有Dto前加上类似"Data“、"DataObject”或“Dto”的后缀？
• 我们在这条道路上走对了吗？如果不是，如何才能使此设计更好？

更新：

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