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

前端之家收集整理的这篇文章主要介绍了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();
原文链接:https://www.f2er.com/aspnet/254376.html

猜你在找的asp.Net相关文章