ServiceStack vs ASP。Net Web API

我想写一个新的REST风格的API，并且已经看了ServiceStack，非常喜欢它。但是，我看到微软已经发布了ASP。Net Web API项目作为新的MVC 4测试版的一部分。有人看过新的Web API项目吗?你能给出每个系统的优缺点吗?

88355 次浏览
小开

他们有非常相似的用例，作为ServiceStack项目的主要维护者，我对ServiceStack的优势和基于消息的设计带来了许多自然的好处有一个很好的洞察。

ServiceStack从2008年开始就作为一个oss运行的项目，其目标只有一个，那就是促进正确设计和实现无摩擦的远程服务。

简洁优雅的设计

为了追求最终的简单性，它是围绕简单优雅的核心构建的——它的大多数功能自然绑定到你的模型，而不是你的控制器——这就是MVC, WebApi所做的(以及微软生产的所有其他Web服务框架)。

采用基于消息的设计为远程服务提供了一种更好的方法，因为它们促进了更可扩展和更不脆弱的服务，简化了访问和调用模式，以及含有许多其他你可以免费获得的天然益处。

作为一项核心任务，我们在每一个阶段都与复杂性作斗争，旨在保持一个不可见的、非侵入性的API，避免引入任何新的概念或人工构造，这些概念和构造对于今天的。net或web服务开发人员来说并不熟悉。

举个例子，你的IService<T>服务实现只是一个标准的带有自动连接依赖的c#类。轻薄的包装器用于围绕核心运行时IHttpRequest和IHttpResponse类型提供一致和统一的API。它们还允许访问底层的ASP。NET或HttpListener的Request和Response类，这样你在使用ServiceStack时就不会受到限制。

与WCF和WebApi相比

下面是ServiceStack和WCF的推广. xml中不同API风格的简要概述。WebApi与WCF的不同之处在于它鼓励REST-ful API设计。至于这两个之间的例子，这是我所知道的唯一一个用ServiceStack和WebApi写的相同服务的例子。

远程服务最佳实践

ServiceStack主要关注简单性、性能和促进web/远程服务最佳实践，围绕采用Martin fowler的远程服务设计模式，尽可能采用惯用的c#:

  • 外观模式 -它建议在跨进程边界通信时使用批处理的粗粒度接口。

  • DTO模式 (MSDN) -指示使用特殊用途的poco来生成web服务响应的有线格式。

  • 网关模式 (MSDN)封装客户端网关/ DTO模型和服务接口层之间的客户端和服务器通信。

这些模式确保了关注点的清晰分离和无摩擦的迭代开发体验。

增强您的服务

ServiceStack web服务的核心是一个无依赖和自动连接的纯c# IService<T>接口，它让你完全自由地用你自己的请求和响应dto定义你的web服务契约，使用干净的POCOs——使ServiceStack的API实际上是不可见的和非侵入性的，也就是说，提取你的c#服务逻辑并在ServiceStack主机之外运行它是很简单的。

这个要点是你用ServiceStack中只有1个c# .cs类得到的一个很好的例子:

  • 所有已注册格式的元数据页
    • 带有指向wsdl、xsd和c#客户端示例的链接
      • 李< / ul > < / >
    • 人性化的HTML报表视图
      • 一个独立的html页面快照(即没有外部引用)。包括嵌入式JSON web服务响应-允许编程访问数据快照。
        • 李< / ul > < / >
      • 内置迷你分析器(优秀的MVC迷你分析器的端口)
        • 包括Sql剖析
          • 李< / ul > < / >
        • JSON/JSONP, XML, JSV, CSV和SOAP端点

        RestServiceBase和ServiceBase类旨在承载您的自定义c#逻辑，以尽可能最大限度地重用，例如，它的dto优先设计简单地允许延迟和代理执行，其中您的相同c#服务也可以托管和执行在MQ主机中，这是当您注册IMessageService，如RedisMQ主机并通过/asynconeway端点调用您的服务时所发生的情况(即c#客户端中的client.SendOneWay())。

        你还可以使用base.ResolveService<T>()方法轻松地委托和创建组合服务，该方法返回所选服务的自动连接实例，如北风客户详情服务示例所示:

        var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });

        返回普通的c#对象

        在大多数情况下，ServiceStack会像预期的那样序列化大多数c#对象——这里有一个可能返回类型的列表(从这个答案):

        • 任何DTO对象->序列化为响应内容类型
        • HttpResult, HttpError, CompressedResult (IHttpResult)用于自定义HTTP响应

        以下类型不进行转换，直接写入响应流:

        • 字符串
        • 流
        • IStreamWriter
        • byte[] -带有application/octet-stream内容类型。

        自定义HTTP报头支持的一个例子可以在这个CORS的例子中看到，其中您可以全局或基于每个服务配置HTTP报头。

        HTML支持

        在ServiceStack中返回详细解释在这里的HTML有多个选项。

        包括。net最快的文本和二进制序列化器

        弹性和快速的序列化器在API中是最重要的，以确保快速的响应时间和一个不破坏现有客户端的可版本API，这就是为什么ServiceStack包含带有NuGet选项的.NET最快的文本序列化器，以启用@marcgravell的协议缓冲区(。NET最快的二进制序列化器)。

        ServiceStack的文本序列化器非常有弹性，可以无错误地承受极端版本控制。

        无摩擦的开发体验端到端

        ServiceStack的自定义特性允许提供快速、类型化、简洁的端到端web服务API，内置支持同步/异步c# /。网和异步Silverlight客户端，无需任何代码生成:

        同步c#实例

        var response = client.Send<HelloResponse>(new Hello { Name = "World!" });

        异步c#示例

        client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });

        因为它只返回纯JSON，所以它也会被其他HTTP客户端使用，例如使用jQuery的JS客户端示例:

        $.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});

        高度可测试的

        所有的c# /。NET ServiceClients共享相同的接口，这使得他们高度可测试的和可交换的点，你可以有相同的单元测试也作为XML, JSON, JSV, SOAP集成测试。

        丰富的验证和错误处理内置

        在提供无摩擦和干净的开发体验的使命中，ServiceStack还包括内置的类型验证和错误处理，其中抛出c#异常或使用其内置的Fluent验证为客户端提供结构化的，类型错误，易于在web服务客户端访问，例如:

        try {
var client = new JsonServiceClient(BaseUri);
var response = client.Send<UserResponse>(new User());
} catch (WebServiceException webEx) {
/*
webEx.StatusCode  = 400
webEx.ErrorCode   = ArgumentNullException
webEx.Message     = Value cannot be null. Parameter name: Name
webEx.StackTrace  = (your Server Exception StackTrace - if DebugMode is enabled)
webEx.ResponseDto = (your populated Response DTO)
webEx.ResponseStatus   = (your populated Response Status DTO)
webEx.GetFieldErrors() = (individual errors for each field if any)
*/
}

        为了使在JavaScript中使用错误变得简单，您可以使用轻量级的ss-validation.js JavaScript库，用一行代码将响应错误简单地绑定到HTML表单字段。SocialBootstrapApi示例项目提供了一个很好的演示。

        丰富的ASP集成。NET和MVC

        ServiceStack MVC PowerPack重写并修复了ASP的许多弊病。NET和MVC，替换其严重的会话和缓存xml拖累的ASP。NET提供了自己的ICacheClient和ISession api的干净和无依赖的实现。

        ServiceStack还包括一个更新更干净的身份验证和自动化提供程序模型，它内置了许多不同的AuthProviders:

        • 凭据-通过发布到/auth/凭据服务，使用用户名/密码凭据进行身份验证
        • 基本认证-允许用户使用基本认证进行认证
        • Twitter OAuth -允许用户在Twitter上注册和认证
        • Facebook OAuth -允许用户注册和认证Facebook

        认证模块是完全可选的，是建立在干净的ICacheClient / ISession api和OrmLite上，它允许你的会话存储在内存，Redis或Memcached和你的UserAuth信息保存在OrmLite支持的RDBMS的SQLServer, MySql, PostgreSQL, Sqlite以及Redis数据存储或InMemory(对开发/测试有用)。

        伟大的文档

        ServiceStack有很好的文档，其中关于框架的大部分信息都托管在GitHub维基上。框架的其他部分(例如Serializers, Redis, OrmLite)的文档可以在servicestack.net/docs/中找到

        ServiceStack。例子项目提供了所有ServiceStack的现场演示和入门模板的源代码，而SocialBoostsrapApi项目提供了一个很好的起点，开发一个Backbone.js单页应用程序与ServiceStack和基于Twitters Bootstrap模板的MVC。

        除了上面的信息宝库是包含在谷歌组内，它在最近几年已经扩展了相当大的规模。

        到处跑

        ServiceStack是一个运行在ASP上的。net 3.5框架。NET和HttpListener托管，可以托管在。NET或Mono上(小知识:www.servicestack.net由CentOS/Mono支持)。这允许您的ServiceStack web服务托管在:

        Windows .NET 3.5 &4.0

        Linux/OSX与Mono

        • Apache + mod_mono
        • Nginx + MonoFastCGI
        • 在动态
        • 控制台应用程序

        使用开源开发模型开发

        ServiceStack是开源开发模型的坚定信徒，它是在开放环境中积极开发的，自成立以来一直托管在自由源码软件许可证 (New BSD)下。到今天为止，它已经收到了来自47个开发人员以上的贡献，目前它位于GitHub上第三受关注的c#项目。

        缺点

        我相信最大的缺点是大多数其他OSS . net项目都不是由微软开发的(甚至不是一个可用的选项)。这意味着它很少是评估框架时的首选。大多数采用者只会把ServiceStack作为最后的手段来评估，他们要么对WCF强加的摩擦和脆弱感到沮丧，要么对首选的Microsoft Stack的性能感到沮丧。

        反馈和社区资源

        ServiceStack已经得到了非常好的接受，大多数人都提供了积极的反馈，他们对它进行了评估，认为邮件群里的积极情绪是可见的。截至今年，@ServiceStack推特账号一直在跟踪在它的收藏夹中提到和反馈。

        社区资源 wiki页面是一个很好的地方，可以找到更多关于ServiceStack在野外的链接，包括博客文章，播客广播，演示文稿，sts等。

小开

有一个新的主要区别需要被解释——从v4开始ServiceStack不再免费使用。因为有一个关于SS pro的非常明确的答案，我想为Web API抛出两个

Web API

职业:

  1. 在你的项目中免费使用(前提是你有一个允许商业使用的VS许可证)
  2. 微软和所有网站都提供了非常高水平的免费支持，包括StackOverflow.com。
  3. 快速集成其他微软技术堆栈，如ASP。NET MVC在微软商店中非常流行
  4. 在Microsoft堆栈中内置了对RESTful身份验证和授权的支持

反对:

  1. 不支持SOAP

辅助的好处

(请随时在下面留下评论，补充为什么Web API有好处或有利弊，我可以补充)

小开

关于ServiceStack我真的不能说太多，但是Web API有很多很棒的特性，目前是版本2。

你可以用Web API做一些事情:

  • OWIN应用程序中的自宿主(即在任何地方运行)。
  • 完全支持async和await。
  • 优秀的默认模板和大量的开源示例。
  • 使用优秀的Json。Net JSON序列化器。
  • 默认为Rest-ish(你必须自己做超媒体)。
  • 和更多的……
小开

作为ServiceStack的客户，对我来说最重要的是ServiceStack的专业知识。

https://github.com/ServiceStack/Issues/issues/606

所以。发现Bug，识别Bug，修复Bug。同样的一天。非凡的支持!

小开
我用SS已经有一年了，一切都很好。 ORMLite是纯粹的魔法。我能够将一个糟糕的MySQL数据库重新映射到一个移动应用程序中。数据库没有变化，因为它是与另一个应用程序的php后端一起使用的

《Mythz》就是一个支持和解释的例子。它提升了我在应用程序设计和简单维护方面的知识。请尝试一下，你就会明白。

另外，不要将SS与WebAPI进行比较。这还不够，SS把更多的东西带到你的工具箱里。ServiceStack。文本也是一个很好的自动工具。


提交答案