ServiceStack vs ASP.Net Web API [关闭]

它们具有非常相似的用例，作为 ServiceStack project 的主要维护者，我对 ServiceStack 的优势和 many natural benefits of its message-based design 有很好的了解。

ServiceStack 自 2008 年以来一直是一个 OSS 运行的项目，其单一目标是促进正确设计和实现无摩擦远程服务。

简约优雅的设计

在追求极致简单的过程中，它围绕 a simple and elegant core 构建 - 它的大部分功能自然绑定到您的模型，而不是您的控制器 - 这是 MVC、WebApi 所做的（以及所有其他 Web微软提供的服务框架）。

采用基于消息的设计为远程服务提供了一种优越的方法，因为它们促进了更具可扩展性和不那么脆弱的服务，简化了访问和调用模式，并且contain many other natural benefits you get for free。

作为一项核心任务，我们在每个阶段都与复杂性作斗争，旨在保持不可见且非侵入性的 API，并避免引入当今 .NET 或 Web 服务开发人员不熟悉的任何新概念或人工构造。

例如，您的 IService<T> 服务实现只是一个具有自动关联依赖项的标准 C# 类。轻量级包装器用于围绕核心运行时 IHttpRequest 和 IHttpResponse 类型提供一致且统一的 API。它们还允许访问底层 ASP.NET 或 HttpListener 的 Request 和 Response 类，因此您在使用 ServiceStack 时永远不会受到限制。

与 WCF 和 WebApi 对比

以下是对 ServiceStack and WCF promote 的对比 API 样式的简要概述。 WebApi 与 WCF 的不同之处在于它鼓励 REST-ful API 设计。至于 2 之间的示例，这是我在两个 ServiceStack and WebApi 中编写的相同服务的唯一已知示例。

最佳实践远程服务

ServiceStack 主要关注简单性、性能和促进 Web/远程服务最佳实践，这些最佳实践围绕着在尽可能惯用的 C# 中采用 Martin Fowlers 远程服务设计模式：

外观模式 - 建议在跨进程边界进行通信时使用批量、粗粒度的接口。

DTO 模式 (MSDN) - 规定使用专用 POCO 来生成 Web 服务响应的有线格式。

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

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

为您的服务赋能

ServiceStack Web 服务的核心以无依赖和自动连接的纯 C# IService<T> 接口为中心，让您可以完全自由地使用干净的 POCO 使用自己的请求和响应 DTO 定义 Web 服务合同 - 实际呈现 ServiceStack 的 API不可见且非侵入性，即提取您的 C# 服务逻辑并在 ServiceStack 主机之外运行它是微不足道的。

这个要点是您通过 just 1 C# .cs class in ServiceStack 获得的一个很好的例子：

所有已注册格式的元数据页面，带有指向 WSDL、XSD 和 C# 客户端示例的链接

带有指向 WSDL、XSD 和 C# 客户端示例的链接

人性化的 HTML 报告视图 一个独立的 html 页面快照（即没有外部引用）。包括嵌入式 JSON Web 服务响应 - 允许以编程方式访问数据快照。

一个独立的 html 页面快照（即没有外部引用）。包括嵌入式 JSON Web 服务响应 - 允许以编程方式访问数据快照。

内置 Mini Profiler（优秀的 MVC Mini Profiler 的移植版）包括 Sql Profiling

包括 Sql 分析

JSON/JSONP、XML、JSV、CSV 和 SOAP 端点

RestServiceBase 和 ServiceBase 类旨在托管您的自定义 C# 逻辑，以尽可能地重用，例如，其 DTO 优先设计允许延迟和代理执行，您的相同 C# 服务也可以在 MQ 主机中托管和执行当您注册像 RedisMQ host 这样的 IMessageService 并通过 /asynconeway 端点（即 C# 客户端中的 client.SendOneWay()）调用您的服务时会发生这种情况

您还可以使用 base.ResolveService<T>() 方法轻松委托和创建复合服务，该方法返回所选服务的自动连接实例，如 Nortwind CustomerDetails Service 示例所示：

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

返回普通的 C# 对象

在大多数情况下，ServiceStack 将按预期序列化大多数 C# 对象 - 以下是可能的返回类型列表 (from this answer)：

任何 DTO 对象 -> 序列化为 Response ContentType

用于自定义 HTTP 响应的 HttpResult、HttpError、CompressedResult (IHttpResult)

以下类型不会被转换并直接写入响应流：

细绳

溪流

IStreamWriter

byte[] - 使用 application/octet-stream 内容类型。

this CORS example 可以看到自定义 HTTP 标头支持的示例，您可以在其中全局或基于每个服务配置 HTTP 标头。

HTML 支持

在 explained in detail here 的 ServiceStack 中有多个返回 HTML 的选项。

包括用于 .NET 的最快的文本和二进制序列化程序

弹性和快速序列化程序在 API 中至关重要，以确保快速响应时间和不破坏现有客户端的可版本化 API，这就是为什么 ServiceStack 包含 fastest text serializers for .NET 和 NuGet 选项以启用 @marcgravell 的 Protocol Buffers （.NET 最快的二进制序列化程序）。

ServiceStack 的文本序列化程序非常灵活，可以withstand extreme versioning 无错误。

端到端的无摩擦开发体验

ServiceStack 的固执己见允许快速、类型化、简洁的端到端 Web 服务 API，内置对 Sync/Async C#/.NET 和 Async Silverlight clients 的支持，无需任何代码生成：

同步 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 客户端使用，例如 JS client example using jQuery：

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

高度可测试

所有 C#/.NET ServiceClient 共享相同的接口，这使它们成为 highly testable 并且可交换到您可以将 相同的单元测试 也用作 XML, JSON, JSV, SOAP Integration Test 的地步。

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

在其提供无摩擦和干净的开发体验的使命中，ServiceStack 还包括 typed validation and error handling 内置，其中抛出 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 example project 提供了一个很好的演示。

与 ASP.NET 和 MVC 的丰富集成

ServiceStack MVC PowerPack 重写并修复了 ASP.NET 和 MVC 的许多问题，替换了它的 crippling Session 并使用自己的 ICacheClient 和 ISession API 的干净且无依赖的实现来缓存受 XML 限制的 ASP.NET 提供程序.

ServiceStack 还包括一个更新、更简洁的 authentication and autorization provider model，其中内置了许多不同的 AuthProvider：

凭据 - 通过发布到 /auth/credentials 服务来使用用户名/密码凭据进行身份验证

基本身份验证 - 允许用户使用基本身份验证进行身份验证

Twitter OAuth - 允许用户在 Twitter 上注册和验证

Facebook OAuth - 允许用户注册和验证 Facebook

Authentication 模块是完全可选的，它建立在干净的 ICacheClient / ISession API 和 OrmLite 之上，它允许您的 Session 存储在 Memory、Redis 或 Memcached 中，并且您的 UserAuth 信息持久保存在 OrmLite 支持的 SQLServer、MySql、PostgreSQL、Sqlite 的 RDBMS 中以及 Redis 数据存储或 InMemory（对开发/测试有用）。

很棒的文档

ServiceStack 有很好的文档记录，其中有关框架的大部分信息都托管在 GitHub wiki 上。可以在 servicestack.net/docs/ 上找到框架其他部分（例如序列化程序、Redis、OrmLite）的文档

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

除了上述信息之外，contained within the Google Group 是一个信息宝库，近年来它的规模扩大了很多。

到处跑

ServiceStack 是一个运行在 ASP.NET 和 HttpListener 主机上的 .NET 3.5 框架，可以托管在 .NET 或 Mono 上（小知识：www.servicestack.net 由 CentOS/Mono 提供支持）。这允许您的 ServiceStack Web 服务托管在以下任一平台上：

带有 .NET 3.5 和 4.0 的 Windows

IIS 5/6/7（使用 IHttpHandler）

VS.NET WebDevServer

控制台应用程序或 Windows GUI

视窗服务

带有单声道的 Linux/OSX

阿帕奇 + mod_mono

Nginx + MonoFastCGI

XSP

控制台应用

使用开源开发模型开发

ServiceStack 是开源开发模型的坚定支持者，在该模型中它以开放的方式积极开发，并且从一开始就一直托管在 liberal OSS licence（新 BSD）下。截至今天，它已收到超过 47 developers 的贡献，目前位于 3rd most watched C# project on GitHub。

缺点

我相信，对于大多数其他 OSS .NET 项目来说，最大的缺点是相同的，因为它不是由 Microsoft 开发（甚至列为可用选项）。这意味着在评估框架时，它很少是首选。大多数采用者只会将 ServiceStack 作为最后的手段来评估，他们要么对 WCF 的摩擦和脆弱性感到沮丧，要么对首选 Microsoft Stack 的性能感到沮丧。

反馈和社区资源

ServiceStack 受到了好评，大多数人都提供了积极的反馈，他们将其评估为 the positive sentiment in the mailing group 可见。截至今年，@ServiceStack twitter 帐户一直在跟踪 mentions and feedback in its favorites。

Community Resources wiki 页面是了解更多有关 ServiceStack 的好地方，其中包含指向博客文章、Pod Casts、演示文稿、Gists 等的链接。

---

有一个新的主要区别需要考虑 - 从 v4 开始，ServiceStack 不再免费使用。由于 SS pro 有一个非常明确的答案，我想为 Web API 抛出几个

网络 API

专业人士：

在您的项目中免费使用（前提是您拥有允许商业使用的 VS 许可证） 可从 Microsoft 和整个网络（包括 StackOverflow.com 上的此处）获得非常高水平的免费支持。快速与其他 Microsoft 技术堆栈集成，例如在 Microsoft 商店中非常流行的 ASP.NET MVC 内置支持 Microsoft 堆栈中的 RESTful 身份验证和授权

缺点：

不支持 SOAP

辅助福利

（请随时在下面留下评论，以说明为什么 Web API 有好处或有我可以添加的优点/缺点）

---

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

您可以使用 Web API 执行的一些操作：

在 OWIN 应用程序中自托管（即在任何地方运行）。

完全支持异步和等待。

良好的默认模板和大量开源示例。

使用了很棒的 Json.Net JSON 序列化器。

默认情况下是 Rest-ish（你必须自己做超媒体）。

和更多...

---

作为 ServiceStack 的客户，这里是 ServiceStack 的专业人士，对我来说最重要。

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

所以。发现错误，识别错误，修复错误。同一天。难得的支持！

---

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

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

另外，不要将 SS 与 WebAPI 进行比较。这还不够，SS 给你的工具箱带来了更多。 ServiceStack.Text 也是一个很棒的 Automapper。

---