让我们看一个非常简单的ASP.NET MVC web应用程序，通过视图呈现产品。它使用控制器，视图，模型和视图模型。
让我们假设我们有一个产品模型，它被持久化到一个文档数据库中。让我们假设我们有一个Productviewmodel的viewmodel，它从Product和MVC Razor View / PartialView中显示。
所以这是一个web端的东西。现在让我们假设我们要添加一个服务返回产品到各种客户端，如Windows 8应用程序。
请求/响应类是否完全与我们已经有的？我们的Productviewmodel可能已经包含了我们要从服务返回的所有内容。
因为我们已经有了Product(模型类)，我们不能在API命名空间中有另一个Product类。但是我们可以，但是这使得事情不清楚，我想避免。
那么，我们应该在API命名空间中引入独立的ProductRequest类和ProductRequestResponse(继承Productviewmodel)类吗？
像这样ProductRequestResponse：Productviewmodel？
我说的是，我们已经有Model和viewmodel类，并为SS服务构建Request和Response类，我们将创建另外两个文件，主要是通过复制我们已经有的类的一切。这对我看起来不是干的，它可能遵循分离关注指南，但是DRY也很重要，实际上分离一切(分离一切导致代码重复)。
我想看到的是一个Web应用程序已经制作的情况，它目前有Models和viewmodels，并返回相应的视图在Web上显示，但可以扩展到一个功能齐全的服务，以支持程序化客户端？像AJAX客户端等…与我们已经有了。
另一件事：
您将看到有电影请求类和电影请求类(一个用于单个电影请求，另一个用于电影列表)。因此，还有两个服务，MovieService和MoviesService，一个处理对单个电影的请求，另一个处理电影类型。
现在，虽然我喜欢SS方法的服务，我认为这是正确的，我不喜欢这种分离只是因为请求的类型。如果我想通过导演看电影怎么办？我会发明另一个请求类有一个Director属性和另一个服务(MoviesByDirector)吗？
我认为样本应该面向一个服务。一切必须处理电影的事情都需要在一个屋檐下。如何用ServiceStack实现呢？
public class ProductsService : Service
{
private readonly IDocumentSession _session;
private readonly ProductsHelperService _productsHelperService;
private readonly ProductCategorizationHelperService _productCategorization;
public class ProductRequest : IReturn<ProductRequestResponse>
{
public int Id { get; set; }
}
// Does this make sense?
// Please note,we use Productviewmodel in our Views and it holds everything we'd want in service response also
public class ProductRequestResponse : Productviewmodel
{
}
public ProductRequestResponse GetProducts(ProductRequest request)
{
ProductRequestResponse response = null;
if (request.Id >= 0)
{
var product = _session.Load<Product>(request.Id);
response.InjectFrom(product);
}
return response;
}
}
解决方法
您可以在整个系统中创建的最重要的接口是您面向外部的服务合同，这是您的服务或应用程序的消费者将绑定到的，即现有的调用网站，通常不会随代码一起更新-base – 所有其他模式是次要的。
DTO是远程服务的最佳做法
在针对远程服务(MSDN)的Martin Fowler’s recommendation for using DTOs(数据传输对象)之后，ServiceStack鼓励使用干净，未保留的POCO来定义一个明确定义的合同，该合同应该保存在一个基本上实现和依赖的.dll中。这样做的好处是，您可以在C#/.NET clients中重复使用用于定义服务的类型化DTO – 提供端到端类型的API，而不使用任何代码生成或其他人工机械。
DRY vs Intent
保持事物DRY不应该与明确的意图混淆，你应该避免尝试DRY或hide behind inheritance，魔法属性或任何其他机制。拥有干净，定义良好的DTO提供了一个单一的参考源，任何人都可以查看每个服务接受和返回的内容，它允许您的客户端和服务器开发人员立即开始工作，并绑定到外部服务模型，而不实现已被写。
保持DTO分离还可以让您在不中断外部客户端的情况下重新实现实现，即您的服务开始缓存响应或利用Nosql解决方案填充您的响应。
它还提供了用于创建自动生成的元数据页面，示例响应，Swagger支持，XSD，WSDL等的权威源代码(没有泄露或耦合在应用程序逻辑中)。
Using ServiceStack’s Built-in auto-mapping
虽然我们鼓励保留单独的DTO模型，但您不需要维护自己的手动映射，因为您可以使用映射器(如AutoMapper)或使用ServiceStack的内置Auto Mapping支持，例如：
创建一个新的DTO实例，在viewmodel上填充匹配的属性：
var dto = viewmodel.ConvertTo<MyDto>();
初始化DTO，并在视图模型上使用匹配的属性填充它：
var dto = new MyDto { A = 1,B = 2 }.PopulateWith(viewmodel);
初始化DTO，并在视图模型上使用非默认匹配属性进行填充：
var dto = new MyDto { A = 1,B = 2 }.PopulateWithNonDefaultValues(viewmodel);
初始化DTO并使用在视图模型上使用Attr Attribute注释的匹配属性填充它：
var dto = new MyDto { A=1 }.PopulateFromPropertiesWithAttribute<Attr>(viewmodel);
当映射逻辑变得更复杂时，我们喜欢使用扩展方法来保持代码DRY并将映射维持在一个可以在应用程序中轻松使用的地方，例如：
public static class MappingExtensions
{
public static MyDto ToDto(this Myviewmodel viewmodel)
{
var dto = viewmodel.ConvertTo<MyDto>();
dto.Items = viewmodel.Items.ConvertAll(x => x.ToDto());
dto.CalculatedProperty = Calculate(viewmodel.Seed);
return dto;
}
}
现在可以轻松地消耗只是：
var dto = viewmodel.ToDto();
