REST API 中对象的设计模式？答案

【问题标题】：Design Patterns for Objects in REST API's?REST API 中对象的设计模式？
【发布时间】：2012-02-08 08:20:16
【问题描述】：

我已经使用 WCF Web API 预览构建了一个 REST API，我想构建一个包含您传递给此 API 的类的库（只是为了让 .Net 开发人员的生活更轻松）。应该是没有太多功能的简单 POCO 类。

但在接收端，我为这些类添加一些功能是有意义的。我有一个下面的例子：

[WebInvoke(UriTemplate = "", Method = "POST")]
public Supertext.API.Order Create(Supertext.API.Order apiOrder)
{

这是一个示例 POCO 类：

public class Order
{
    public string Service { get; set; }

    public string OrderTitle { get; set; }

    public string Currency { get; set; }
}

现在，在服务器端扩展此类的好方法是什么？
我想使用子类是行不通的。代表？
实际上有两个不同版本的类？一个用于客户端，一个用于服务器？

其他人在做什么？

【问题讨论】：

【解决方案1】：

向这个 POCO 类添加额外功能的问题是你正在把它变成一个域对象。现在，这个域对象的性质将受到以下事实的约束：从本质上讲，此类充当操作中接口的定义。更改有关此类的详细信息可能会破坏客户端。

将这个类纯粹作为一个数据传输对象保持一个更清晰的模型，其唯一职责是帮助将有线格式桥接到对象并使用诸如AutoMapper之类的映射器将数据从DTO映射到一个真正的领域对象。真正的领域对象完全在您的控制之下，您可以愉快地对其进行重构，而不会威胁到您的服务使用者的级联效应

【讨论】：

好的，但这也意味着我基本上有两次相同的类具有相同的属性，对吧？部分课程呢？这是个坏主意吗？我在这里看到msdn.microsoft.com/en-us/library/cc716747.aspx
最初，这些类可能看起来非常相似，但随着您决定在内部以不同于有线格式的方式表示数据，这可能会随着时间而改变。部分类仍然留下一个具有多种职责的类。单独的类可以更清晰地分离关注点
好的，很公平。会试一试的。
我们有资源类和域类。目前它们有 95% 相同。我们使用 automapper 在它们之间进行映射。我们还分别验证每个。我们使用 t4 从域类中生成资源类