我正在考虑将我的服务层和我的数据层（存储库模式）移动到WCF Rest服务。
所以基本上我会在本地安装我的软件（WPF客户端），它会调用通过Rest服务存在的服务层...然后服务层将使用WCF Rest服务调用我的数据层或者也许只是调用它通过DLL程序集
我希望了解性能会是什么样的。目前，我在本地通过DLL程序集安装了我的数据层和服务层。
另外我假设WCF REST服务不支持方法重载，但是名称相同，但签名不同？
我真的很感激任何人都能给予的任何反馈。
由于
答案 0 :(得分：9)
如果你想要的只是一个公开为Web服务的瘦CRUD层（提供没有VPN的数据库访问等），那么你可以使用WCF Data Services做同样的事情而不需要付出任何努力，并且一些更灵活的东西（例如，你可以将Linq写成代理）。
您所谓的服务层应该公开域对象，因此假设您拥有域模型并希望使用WCF Web服务（REST）公开它或其他方式），您的问题的答案是：
WCF非常快。它显然不是透明，但根据经验，如果您通过网络连接连接到服务，那么您遇到的任何“慢”都将归因于网络本身的延迟/带宽限制。唯一的例外是WCF客户端（即频道）的设置时间 - 这就是为什么你通常希望尽可能长时间保持它们活着的原因，它们不是像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集成以及所有这些好东西。对于公共应用和mashup，REST 很好，但不适合每个场景。
答案 1 :(得分：1)
我个人认为，“纯”数据访问层并不真正有意义地设计为独立服务。如果您知道必须设计一个封装业务逻辑的REST服务，并且无论如何都会为数据添加一层安全性，那么为什么不使用传统的数据访问技术（ADO.NET，NHibernate，ADO.NET） EF等在里面？
另一件需要考虑的事情是，除非你建立在像ADO.NET数据服务这样的技术上，否则设计一个有效的“纯”数据访问层实际上是一项投资，它允许投影，分页，关系管理等。