asp.net-mvc – ServiceStack新服务并发ASP.NET MVC网站

在 examples的ServiceStack我没有看到一个单一的应用程序是ASP.NET MVC网站，然后使ServiceStack服务第二。

让我们看一个非常简单的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客户端等…与我们已经有了。

另一件事：

如果你看看这个例子https://github.com/ServiceStack/ServiceStack.Examples/blob/master/src/ServiceStack.MovieRest/MovieService.cs

您将看到有电影请求类和电影请求类(一个用于单个电影请求，另一个用于电影列表)。因此，还有两个服务，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();

asp.net-mvc – ServiceStack新服务并发ASP.NET MVC网站

解决方法

相关推荐