WCF：使用部分类来拆分复杂的 Web 服务？
我目前正在开发一个 Web 服务，该服务应该公开大量与其交互的方式。
例如，客户端可能能够与 Web 服务交互，以便管理数据库中的用户或项目。
为此，我创建了以下类：
- 两个数据契约：IUsersServiceContract 和 IProjectsServiceContract
- 两个服务契约接口：IUsersServiceContract 和 IProjectsServiceContract
我的问题如下：
创建两个不同的 Web 服务（每个服务都有自己的端点）是否有意义，而不是创建一个实现两个服务契约接口的大类？
请记住，实际上我会有更多的服务契约接口来处理不同类型的数据。
据我了解，使用分部类（拆分为多个文件）将允许我创建一个仅具有一个端点的大型 Web 服务。
这样做的缺点是需要处理一个大类拆分为多个文件的情况，即：如果开发人员“看不到全局”，则更难维护并且更容易出错。
另一种解决方案是为每个服务契约接口实现一个 Web 服务。
本质上，如果我有 X 个服务契约接口，我最终会得到带有 X 个端点的 X Web 服务。
您会选择哪种解决方案？为什么？
感谢您的投入！
I am currently in the process of developing a Web Service which should expose a relatively large number of ways to interact with it.
For example, Clients may be able to interact with the Web Service in order to manage users or projects in a Database.
To that effect, I created the following classes:
- Two Data Contracts: IUsersServiceContract and IProjectsServiceContract
- Two Service Contracts Interfaces: IUsersServiceContract and IProjectsServiceContract
My question is the following:
Does it make sense to create two different Web Services, each with their own endpoint(s), instead of creating one big class that implements both Service Contracts Interfaces ?
Keep in mind that in reality I would have many more Service Contracts Interfaces that deal with different sorts of data.
From what I understand, using a partial class (split in multiple files) will allow me to create one big Web Service with only one Endpoint.
This has the disadvantage of dealing with one big class split in multiple files, i.e: its harder to maintain and more prone to errors if developers "don't see the big picture".
The other solution would be to have one Web Service per Service Contract Interface implemented.
In essence, if I have X Service Contracts Interfaces, I end up with X Web Services with X Endpoints.
Which solution would you choose and why ?
Thanks for your input !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，我不会使用分部类来拆分类；导致 tgis 分裂的巨大规模表明该类太大并且需要重构。在我看来，部分类的主要目的是添加对自动生成的代码的更改。
由于可以使用 web.config 中的命名行为来共享服务和端点配置，因此拆分服务应该不会那么麻烦。但这种拆分应该是出于功能分组的目的。
在不知道您的服务的确切性质的情况下，听起来两种服务可能会自然分离；一种用于用户相关操作，一种用于面向项目的操作。
如果实现类的增长超出了您认为合理的大小，我会考虑让单独的类（或者最好是接口）处理每个方法的内部逻辑，并让服务实现本身成为一个浅层外观，将其自己的方法参数委托给正确的徽标实例
Personally I would not use partial classes for splitting a class; the sheer size motivating tgis split suggests that the class is too large and needs a refactoring. In my opinion partial classes main purpose is to add changes to auto generated code.
Since service and endpoint configuration can be shared using named behaviours in web.config splitting the service should not be that cumbersome. But the split should be motivated by grouping of functionality.
Without knowing the exact nature of you services it sounds like there could be a natural separation in two services; one for user related operations and one for project oriented operations.
If the implemantation classes grows above what you think are reasonable sizes I would consider letting separate classes - or preferably interfaces - handle each methods inner logic and let the service implementation it self be a shallow facade that delegates its own method parameters to the correct logoc instance
当您谈论 n 个服务合同时，这里需要考虑的一件重要事情是与实施每个服务合同相关的成本。这里有一篇很好的博客文章，"服务合同保理和设计”，尽管如果不是 Juval Lowy 发布这篇文章，那么显然有人在抄袭他（我指的是 Juval 的书 - “Programming WCF Services”页面） 93）。
An important thing to consider here, when you're talking about n number of service contracts, is the cost associated with implementing each service contract. There's a good blog post on that here, "Service Contracts Factoring and Design", although if it wasn't Juval Lowy who posted this article then someone is clearly ripping him off (I am referring to Juval's book - "Programming WCF Services" page 93).