WCF-有多少方法太多了？

Question

我目前正在开发一个按设计具有三层架构的应用程序。它由管理网站，WCF Web服务和数据库组成。当然，网站不直接连接到数据库，因此所有请求和响应都必须通过该服务。 “问题”是这个应用程序中涉及多个实体，并且对于每个实体我必须支持基本的CRUD操作等等，这使得服务现在在单个端点中有30多种方法。由于我已经不得不增加最大邮件大小，我开始问自己，在单个服务中是否拥有所有这些方法并不是太多。你怎么看？我有哪些替代方案？

Answer 1

我无法给你一个好的答案，因为它取决于你的应用程序的要求和复杂性。通常，CRUDy服务接口是您应该避免的反模式。您的数据层和服务层之间不应存在一对一的映射。如果有，那么服务层有点不拉它自己的重量。 SOA是一个很大的话题，我只是开始理解，但我的理解是SOA应该封装许多操作的逻辑。即（身份验证，授权，记录，扩展，交易等）

http://msdn.microsoft.com/en-us/library/ms954638.aspx

您是否听说过Repository模式？这是一种软件设计模式，其中特定的类/程序集封装了将数据导入和导出数据库所需的逻辑。它比使用完整的服务更轻，如果您想要的是将应用程序与数据库分离的好方法，可能就是您所需要的。 Repository模式的一个非常巧妙的功能是，您可以将Repository的所有方法都设置为一个接口，然后创建一个MockImplementation来独立于您的数据库对您的业务/ UI层执行测试。

http://msdn.microsoft.com/en-us/library/ff649690.aspx

Answer 2

这个问题没有真正具体的答案。这是一种权衡。尽量保持单一责任原则。有两种选择：

• 为每种数据类型创建一个端点，将CRUD操作放入每个端点。这意味着要通过。维护更多的端点配置。
• 将您的方法分成多个文件，但使用部分类将它们保留在一个类中。
• 如果你所做的只是针对每种数据类型的CRUD操作，那么可以改用WCF数据服务/ OData。

Answer 3

在WCF服务上实现重复的CRUD功能可能会很痛苦，但如果服务未全局公开（因此您无需为身份验证/授权付出太多代价），则可以通过使用节省大量时间两者之一：ADO.NET数据服务或WCF RIA服务。

单个服务上的30个方法是否是一个糟糕的设计 - 这一点尚不清楚。这就像问一个有30个成员的班级是不是一个糟糕的设计 - 有些人会说它肯定是，大多数人会评论“这取决于你在做什么”。

然而，使用HTTP进行CRUD会带来一些限制 - 其中一个就是你提到的。除非增加邮件大小，否则无法插入/更新大批量。除非您以某种方式通过http以明确的方式处理事务，否则您还可能遇到一些严重的事务处理问题。