mar*_*ith 3 c# rest wcf repository-pattern
我正在考虑将我的服务层和我的数据层(存储库模式)移动到WCF Rest服务.
所以基本上我会在本地安装我的软件(WPF客户端),这将调用通过Rest服务存在的服务层...然后服务层将使用WCF Rest服务调用我的数据层或者也可以通过DLL程序集
我希望了解性能会是什么样的.目前,我在本地通过DLL程序集在本地安装了我的数据层和服务层.
另外我假设WCF REST服务不支持方法重载,但是具有相同的名称,但具有不同的签名？
我真的很感激任何人都能给予的任何反馈.
谢谢
如果你想要的是公开为Web服务的薄CRUD层(提供不使用VPN等数据库访问),那么你可以用做同样的事情WCF数据服务没有所有的努力,并有东西,这是一个很大的更灵活(例如,您可以针对代理编写Linq).
你所谓的服务层应该暴露域对象,所以假设你有一个域模型并希望使用WCF Web服务(REST或其他)公开它,你的问题的答案是:
WCF非常快.它显然不透明,但根据经验,如果您通过网络连接连接到服务,那么您遇到的任何"慢"都将归因于网络本身的延迟/带宽限制.唯一的例外是WCF客户端(即通道)的设置时间 - 这就是为什么你通常希望尽可能长时间保持它们活着的原因,它们不是像a的一次性对象DataContext.
线路不支持方法重载.您可以重载服务程序集中的方法并通过OperationContract属性(特别是Name属性)区分它们,但对于外部客户端,它们看起来是具有不同名称的不同Web方法.
但是,如果您正在设计Web服务,甚至是REST服务,那么您需要做的第一件事就是将您的视角从基于RPC("功能")的思维模式转变为基于文档的("消息")思维模式.换句话说,您应该定义一个"请求"类,它将所有这四个参数公开为属性,而不是让4个方法采用4个可能参数的不同组合.这通常被认为是"本地"代码的糟糕设计,但它是Web服务的良好设计.
同样,使用Web服务来公开"存储库"通常被认为是反模式(WCF数据服务除外,它的用途非常不同).原因是Web服务应该提供业务逻辑(我假设是您的服务层所做的).它应该提供非常粗粒度的操作,原子事务,客户端提供同时执行单个完整事务所需的所有信息,而不是连续调用多个方法.
换句话说,如果您发现,在尝试将服务转换为Web服务时,为了执行单个"工作单元",必须在多个不同的服务上调用多个操作,那么您应该考虑将服务重新设计为提供更好的工作抽象.整体设计应尽量减少客户端和服务之间的"喋喋不休".
因此,要总结,它可能使很少的感觉让你有一种生活进行对话的多数民众赞成公开为Web服务的"数据层",在客户端上的"服务层" ,除非你需要解决非常具体提供的问题通过WAN进行CRUD操作.从体系结构的角度来看,更有意义的是通过WCF 公开实际服务,并转向更瘦客户端的应用程序.
但是,请记住,沿着"SOA"路径走下去虽然它可能有许多长期的好处,但可能会引起一些短期的痛苦.您基本上有另一个要维护的库,另一个要测试的库,另一个失败点,另一个需要记录的东西.如果您没有大型分布式体系结构,或者计划在不久的将来,那么将WCF服务集成到顶部提到的WCF数据服务框架之外可能为时尚早.
此外,您没有指定您正在开发的域或应用程序类型,但REST作为特定服务模型在安全性,分布式事务等方面进行了许多权衡.如果这些服务是用于内部的或者B2B消费 - 即如果它们是"企业"服务 - 你真的应该考虑使用SOAP,它可以让你访问WS-Security,Active Directory集成以及所有好东西.REST 非常适合公共应用程序和mashup,但并不适合所有场景.