我正在考虑将我的服务层和数据层（存储库模式）移动到 WCF Rest 服务。
所以基本上我会在本地安装我的软件（WPF 客户端），它会调用通过 Rest 服务存在的服务层...然后服务层也会使用 WCF Rest 服务调用我的数据层，或者可能只是调用它通过 DLL 程序集
我希望了解表演会是什么样子。目前，我通过 DLL 程序集在本地安装了我的数据层和服务层。
我还认为 WCF REST 服务不支持重载方法重载具有相同的名称但具有不同的签名？？
如果有人能提供任何反馈，我将不胜感激。
谢谢
【问题讨论】：
标签： c# wcf rest repository-pattern
如果您想要的只是一个作为 Web 服务公开的精简 CRUD 层（以提供无需 VPN 的数据库访问等），那么您可以使用 WCF Data Services 做同样的事情而无需付出所有努力，并拥有一些更加灵活（例如，您可以针对代理编写 Linq）。
您调用的服务层应该公开域对象，因此假设您有一个域模型并希望使用 WCF Web 服务（REST或其他），您的问题的答案是：
WCF 非常快。这显然不是透明，但根据经验，如果您通过网络连接连接到服务，那么您遇到的任何“缓慢”都将是由于网络本身的延迟/带宽限制。唯一的例外是 WCF 客户端（即通道）的设置时间 - 这就是为什么您通常希望它们尽可能长时间地保持活动状态，它们不是像 DataContext 这样的一次性对象。
不支持通过线路重载方法。您可以重载服务程序集中的方法并通过OperationContract 属性（特别是Name 属性）区分它们，但对于外部客户端来说，它们看起来是具有不同名称的不同Web 方法。
然而，如果您正在设计 Web 服务，甚至是 REST 服务，您需要做的第一件事就是从基于 RPC（“函数”）的思维方式转变您的观点到基于文档（“消息”）的一个。换句话说，您应该定义一个“请求”类，将所有 4 个参数作为属性公开，而不是让 4 个方法接受 4 个可能参数的不同组合。对于“本地”代码，这通常被认为是糟糕的设计，但对于 Web 服务来说却是好的设计。
同样，使用 Web 服务公开“存储库”通常被认为是一种反模式（WCF 数据服务除外，它的用途非常不同）。原因是 Web 服务应该提供 业务逻辑（我假设这是您的服务层所做的）。它应该提供非常粗粒度的操作、原子事务，其中客户端提供所有同时执行单个完整事务所需的信息，而不是连续调用多个方法。
换句话说，如果您在尝试将服务转换为 Web 服务时发现有必要在多个不同的服务上调用多个操作以执行单个“工作单元”，那么您应该考虑重新设计为工作提供更好的抽象的服务。整体设计应尽量减少客户和服务之间的“喋喋不休”。
总而言之，拥有一个位于客户端上的“服务层”与作为 Web 服务公开的“数据层”对话可能没有什么意义，除非您需要解决通过 WAN 提供 CRUD 操作的非常特定问题。从架构的角度来看，更有意义的是通过 WCF 公开实际的服务，并转向更多的瘦客户端应用程序。
不过，请记住，走“SOA”之路虽然可能带来许多长期利益，但也可能会带来一些短期痛苦。你基本上有另一个库要维护，另一个库要测试，另一个故障点，另一个你需要记录的东西。如果您没有大型的分布式架构，或计划在不久的将来，那么开始在顶部提到的 WCF 数据服务框架之外集成 WCF 服务可能还为时过早。
此外，您无需指定要开发的领域或应用程序的类型，但作为特定服务模型的 REST 会在安全性、分布式事务等方面进行一些权衡。如果这些服务是用于内部或 B2B 消费——即，如果它们是“企业”服务——你真的应该考虑使用 SOAP，它可以让你访问 WS-Security、Active Directory 集成和所有这些好东西。 REST 非常适合公共应用程序和混搭，但不适用于每个场景。
【讨论】：
我个人的看法是，将“纯”数据访问层设计为独立服务并没有真正意义。如果您知道您必须设计一个 REST 服务来封装您的业务逻辑并为数据添加一层安全性，那么您为什么不使用传统的数据访问技术（ADO.NET、NHibernate、ADO.NET EF等）在里面？
要考虑的另一件事是，除非您要构建像 ADO.NET 数据服务这样的技术，否则设计一个允许投影、分页、关系的高效“纯”数据访问层实际上可能是一项相当大的投资管理等。
【讨论】：