WCF：使用分部类拆分复杂的Web服务？

我目前正在开发一个Web服务，它将公开相对大量的与之交互的方法

例如，客户机可以与Web服务交互，以便管理数据库中的用户或项目

为此，我创建了以下类：

• 两个数据合同：IUsersServiceContract和IProjectsServiceContract
• 两个服务合同接口：IUsersServiceContract和IProjectsServiceContract

我的问题如下：

创建两个不同的Web服务，每个Web服务都有自己的端点，而不是创建一个实现两个服务接口的大型类，这有意义吗

请记住，在现实中，我会有更多的服务契约接口来处理不同类型的数据

据我所知，使用分部类（拆分为多个文件）将允许我创建一个只有一个端点的大型Web服务

这样做的缺点是处理多个文件中的一个大类拆分，即：如果开发人员“看不到全局”，则更难维护，更容易出错

另一个解决方案是每个服务契约接口实现一个Web服务

本质上，如果我有X个服务契约接口，那么我最终会得到X个端点的X个Web服务

您会选择哪种解决方案？为什么

---

谢谢你的意见

就个人而言，我不会使用分部类来拆分类；激发tgis分裂的巨大规模表明该类太大，需要重构。在我看来，分部类的主要目的是为自动生成的代码添加更改

由于可以使用web.config中的命名行为共享服务和端点配置，因此拆分服务应该不会那么麻烦。但拆分应该由功能分组来驱动

在不知道您服务的确切性质的情况下，听起来两个服务可能会自然分离；一个用于与用户相关的操作，另一个用于面向项目的操作

---

如果实现类超出了你认为合理的大小，我会考虑让单独的类——或者最好是接口——处理每个方法的内部逻辑，让服务实现本身成为一个浅表面，将自己的方法参数委托给正确的LoGoc实例

一个重要的事情考虑这里，当你谈论N个服务合同时，是与实现每个服务合同相关的成本。这里有一篇很好的博客文章，虽然如果不是Juval Lowy发表了这篇文章，那么显然有人在欺骗他（我指的是Juval的书——《WCF服务编程》第93页）。

谢谢Faester，你的评论证实了我对部分课程的担忧。我也很感谢你的意见，我会遵循你的指导方针。但有一个问题，您所说的“可以使用web.config中的命名行为共享服务和端点”是什么意思？（我刚刚习惯WCF:））。我知道可以使用行为“配置”服务和端点，但我不确定共享服务和端点是什么意思？你的意思是行为本身可以被分享吗？对不起，这是一个打字错误。正如你所说，我的意思是共享配置。（大多数人讨厌配置WCF，为什么在这里重用是个好主意，因为到处都是。打字错误现在已经纠正了。）我很高兴知道你可以使用我的评论：）