SOA 中是否需要每个用例的 DTO？答案

【问题标题】：DTO per use case necessary in SOA?SOA 中是否需要每个用例的 DTO？
【发布时间】：2012-05-11 15:42:56
【问题描述】：

我收到的要求是只要求写入和更新某些属性，但要读取所有属性，所以我想知道处理这个问题的最佳方法是什么？我知道这听起来很疯狂，但要求是写入/更新将通过 SOAP 完成，而读取将通过 REST 完成。想法是 SOAP API 将用于初始数据加载，Web 界面的最终用户将进行更详细的修改，然后另一组最终用户将针对 REST API 进行编程以在网页上显示数据。我会很感激一些关于最佳/良好实践的反馈和/或 cmets。这是我认为需要做的事情（注意，缩写示例）：

namespace DTOs.Create
{
    public class Project
    {
        public string Name { get ; set; }
    }
}


namespace DTOs.Read
{
    public class Project
    {
        public string Name { get ; set; }
        public string Description { get ; set; }
        public DateTime DueDate { get ; set; }
        public int Priority { get ; set; }
    }
}

【问题讨论】：

您能否仅使用命名空间 DTOs.Read 中的一个类属性来实现相同的效果，并拥有 2 个方法，一个 REST 执行 WebGet 并且不通过 SOAP 公开，而其他方法（创建/更新）公开仅通过 SOAP。

标签： wcf c#-4.0 rest soap soa

【解决方案1】：

考虑实施的生命周期。如果其余接口和soap 接口可能会随着时间的推移而出现分歧，那么一定要使用两个不同的DTO 类。

根据您的具体情况，我会保留两个 DTO 以放松这两个接口。我在项目中听到太多次诸如“我们不能只改变界面的这个精简部分吗？它只是一个字符串！”然后要花费太多精力来实现，因为接口与应用程序的其他部分紧密耦合，这些部分也必须重写（重新测试）等。

但这在很大程度上取决于应用程序的范围

【讨论】：

【解决方案2】：

我倾向于只有一个 DTO，DTO 的目的是携带数据，它不应该附加行为语义，服务操作提供了这一点。

您应该能够在许多不同的上下文中（在不同的操作中）使用项目信息 (DTO)。

如果定义项目的定义在 SOAP 和 REST 部分之间不同，那么您的域中对项目的定义应该保持一致，您还有其他问题。

随着时间的推移，这两个接口可能会出现分歧，但分歧在于数据的使用方式，而不是数据的本质。

如果一个界面真的需要这样不同的信息，不如创建一个新的领域概念，因为它不再是原来的项目概念。

【讨论】：