[置顶] WCF替代方案ServiceStack
https://github.com/ServiceStack/ServiceStack/wiki
为什么Servicestack
- 入门
- 参考
- 客户端
- 格式
- 视图引擎
- 主机
- 先进
- 插件
- 测试
- 其他语言
- 使用案例
- 性能
- 如何
- 未来
在现代发达国家,服务堆栈提供了一个替代的,更清洁的的POCO驱动方式创建Web服务。
- 简单
- 速度
- 最佳实践
- 模型驱动,代码优先,无摩擦发展
- 无XML配置,无代码生成- 常规驱动!
- 灵动。强类型的DTO推断情报
- 净和单声道
- 高测试 -服务完全脱钩HTTP
- 一直围绕ServiceStack 4年以上
特点:
- XML,JSON,SOAP和更多!
- 内置验证 -与智能流畅的语法!
- 自动异常处理
- 缓存(** Memcached的**和Redis的支持的盒子!)
- 认证/授权(内置的OAuth提供商Twitter / Facebook的)
马丁·福勒数据传输对象模式ServiceStack定义Web服务
服务栈,严重影响了马丁·福勒数据传输对象模式:
当你正在使用一个远程接口,如远程门面(388),每次调用是昂贵的。因此,您需要,以减少调用的次数,这意味着你每次调用需要传输更多的数据。做到这一点的方法之一是使用大量的参数。然而,这往往是尴尬程序 - 事实上,它往往是不可能的语言,如Java,只返回一个单一的值。
解决的办法是创建一个数据传输对象,可以容纳所有的数据调用。它必须是可序列化的跨越连接。汇编一般是用来在服务器端,DTO和任何域对象之间的数据传输。
DTO是用来定义Web服务的ServiceStack请求和响应的标准POCO同时实施只需要继承和依赖免费IService的<TRequestDto>的,
可测试的。保持你的DTO在一个单独的依赖。DLL作为奖励,你可以重新使用他们在你的C#/
NET客户端提供一个强类型的API,无需任何代码根是什么,这样的一次。DTO 一切服务栈的定义,不污染您的Web服务的任何额外的自定义文物或标记。
服务栈使用自定义上述文物和零配置,对开发商不施加任何额外负担的情况下,增加了探索的能力,并提供托管你的web服务的今天,包括一些不同的物理端点:XML (+ REST),JSON(+ REST),:JSV(+ REST)和SOAP 1.1 / SOAP 1.2。
WCF反DTO的Web服务框架,
不幸的是,这个最佳实践惯例是由微软的WCF SOAP Web服务框架,有效地劝阻他们鼓励你发展特定API的RPC方法调用,通过强制使用方法签名来定义你的Web服务API。这样的结果可重复使用的少,更多的客户特定的API,鼓励更多的远程方法调用。
感到不满,在WCF这种抗病毒药模式,提供一个Web服务队的最佳实践框架,拥抱调用远程服务,使用配置,以公约为基础的DTO的ServiceStack出生。
ServiceStack鼓励发展消息样式,可重复使用和批量满Web服务
整个的POCO类型被用来定义请求和响应的DTO,以促进建立良好定义的粗粒度的Web服务。基于消息的接口时,是最好的做法,因为他们更多的工作,使用较少的网络电话可以批量处理的过程调用,最终更可重复使用的相同的操作可以被称为使用不同的调用语义。这是WCF的操作或RPC风格的,特定于应用程序的Web服务的服务合同,鼓励使用方法签名来定义每个操作形成了鲜明的对比。
它矗立在今天的通用计算,有没有更昂贵的,你可以做的比远程网络通话。虽然新手开发人员更容易,使用方法定义Web服务操作,WCF促进坏的做法,鼓励他们设计和对待像正常功能的web服务调用调用,即使它们是数百万次慢。特别是在应用程序服务器层,没有什么伤害比多个依赖和同步Web服务调用的客户端和服务器的性能和可伸缩性。
批次满,基于消息的Web服务非常适合SOA服务的发展,因为它们导致更少,更丰富,更可重复使用的Web服务,需要保持。RPC风格的服务,从客户端的角度来看,这是一个单一的应用程序的数据访问方案的要求的结果通常表现。单个应用程序来来去去,随着时间的推移,你的数据和服务准备流连的长远。理想情况下,你要想想你的web服务的定义从一个服务和数据的角度来看,你如何可以使您的数据,所以它是由你的客户更可重复使用的。
RPC的健谈和基于消息的API之间的差异
public interface IService
{
Customer GetCustomerById(int id);
Customer[] GetCustomerByIds(int[] id);
Customer GetCustomerByUserName(string userName);
Customer[] GetCustomerByUserNames(string[] userNames);
Customer GetCustomerByEmail(string email);
Customer[] GetCustomerByEmails(string[] emails);
}
对比同等的基于消息的服务:
public class Customer { int[] Ids; string[] UserNames; string[] Emails; } public class CustomersResponse { Customer[] Results; }
1远程调用可以达成任何以上的组合,由同一个Web服务 - ,即什么ServiceStack鼓励!
批次全方位的服务更少,而且更需要较少的维护和促进更多的可重复使用的,高效的服务的发展。此外,消息的API更弹性的变化,你能够安全地添加更多的功能,或返回不打破或需要重新根现有客户的更多的数据。基于消息的API也借给他们更好缓存,异步,递延,代理和可靠的执行与经纪人和代理使用。
相比之下,几乎没有胜利远程RPC API,但也许隐藏方法进行远程调用的样子,甚至存在一个远程服务调用,即使他们是百万次的速度较慢,导致新的开发,开发效率低,脆性系统从一开始。