单个端点地址处的 WCF 大型接口
我有一个 wcf 服务，它在单个端点地址上公开大量服务方法。到目前为止，所有服务方法都是在单个服务契约类中实现的。该服务契约类实现了多个服务契约接口。现在我想将服务契约方法的实现分成几个类，以避免契约类变得很大。我使用带有 ServiceHost 的自托管方案。 ServiceHost 仅采用实现服务方法的单一类型的类型，因此似乎所有内容都必须在此类中实现。当然，这些方法的实质可以分解为几个类。但是有没有办法将方法分成几个类呢？
I have a wcf service that exposes quite a large number of service methods on a single endpoint address. Up to now, all service methods are implemented in a single service contract class. This service contract class implements several service contract interfaces. Now I would like to split the implementation of of the service contract methods into several classes in order to avoid the contract class from growing to big. I use a self hosting scenario with a ServiceHost. The ServiceHost just takes the type of one single type implementing the service methods, so it seems that everything has to be implemented in this class. Of course the flesh of the methods can be factored out into several classes. But is there also a way to split the methods into several classes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以将服务实现为部分类，这样您就可以拆分实现到多个文件。
如果要求保留单个端点和单个接口，则没有其他方法可以将其拆分 - 您创建的一个类必须实现所有接口。
我建议保持服务实现尽可能简单，并且让每个方法都是一个单行函数，将操作委托给实际实现，然后可以将其拆分为多个类。也许每次手术都制作一个更有意义？这是我以前成功使用过的模式。
You can implement the service as a partial class, which lets you split the implementation to multiple files.
If the requirement is to keep a single endpoint and a single interface, then there is no other way of splitting it up - the one class you create must implement all of the interface.
I would suggest to keep the service implementation as simple as possible, and just have each method be a one-liner that delegates the operation to the actual implementation, which can then be split over multiple classes. Perhaps it would even make sense to make one per operation ? That is a pattern I have used before with success.
您可以根据需要创建任意数量的服务合约，每个合约背后都有自己的逻辑。
正如您所希望的那样，这种方法的优点是将相关功能按逻辑分组在一起。
缺点是调用客户端现在必须知道调用该函数时要使用哪个服务。
You can create as many Service contracts as you desire, each with its own logic behind it.
The up-side of this approach is, as it seems you desire, to logically group together related functions.
The down-side is that the calling client must now know which service to use when calling the function.
这是限制服务中操作数量的好方法。据我了解，您目前的情况是，您有一个服务实现，它实现了多个服务合同。这意味着您的服务上已经有多个端点 - 每个端点都公开单个合约。在这种情况下，您的客户已经准备好为每个所需的合同创建单独的代理。
现在您想将服务实现类划分为多个服务实现。每个服务实现将实现一个（或较小的一组）服务合同。这将需要修改您的托管应用程序 - 每个服务实现都需要单独的 ServiceHost。您还需要为每个服务实现单独的配置和唯一的地址。
客户端可以用新服务重新创建，但我认为也应该可以简单地更改端点的地址，并且它应该可以工作。
It is good approach to limit number of operations in the service. As I understand your scenario at the moment you have single service implementation which implements several service contracts. This means that you already have multiple endpoints on your service - each enpoint exposes single contract. In that case your client is already prepared to create separate proxy for each needed contract.
Now you want to divide your service implementation class in multiple service implementations. Each service implementation will implement one (or smaller set) of service contracts. This will require modification of your hosting application - you will need separate ServiceHost for each service implementation. You will also need separate configuration and unique address for each service implementation.
Client side can be just recreated with new services but I think it should also be possible to simply change addresses for endpoints and it should work.