扩展WCF服务及其自动生成的客户服务引用。

Question

我对.Net和C#开发还比较陌生，并且有一个问题:将WCF服务与应用程序分离到我正在创建的网络DLL中。DLL的目标是提供一种从服务器和客户端应用程序中托管和访问服务的简单方法，并将一些功能添加到用于心跳和自动重连接的基本服务中，而无需每个应用程序在其WCF服务中指定心跳方法，并让应用程序管理用于自动重连接的计时器。

DLL提供了一个ServiceServer和一个具有以下目标的ServiceClient类：

ServiceServer：

• 创建和管理ServiceHost实例。
• 宿主来自DLL外部的服务(作为泛型传递)。
• 将心跳操作添加到要承载的服务中，以及所有客户机/服务器应用程序所共有的其他操作。

ServiceClient：

• 创建客户端服务引用并使其对客户端应用程序可用。服务引用(自动生成的)也作为一个泛型从application.
• Add心跳方法传递到客户端的服务引用，以及所有客户机/服务器apps.
• Automatic使用计时器或类似的通用操作。

。

到目前为止，我一直试图使用部分类、泛型和静态扩展方法，但没有成功。问题是，为了使我的DLL完全解耦，我使用泛型获得并创建服务引用和服务；我无法使用这些方法来扩展接收到的泛型类型。

我基本上尝试用其他方法扩展客户端服务引用，以便能够发送心跳等等，而不需要另一个独立的连接和服务(这将使心跳无效)，而且客户端应用程序不必知道任何有关发送心跳和自动重连接的信息。同样，我希望扩展服务器类作为参数接收的服务，以添加操作和服务器心跳代码的实现，并最终也扩展其他公共的所有应用程序方法。

Answer 1

您可能希望探索这种解决方案，以便在wcf服务中自动实现心跳。

http://weblogs.asp.net/cibrax/archive/2010/05/17/enabling-service-availability-in-wcf-services.aspx

该解决方案还为客户端提供了扩展方法。

谢谢巴勃罗。

Answer 2

不，不会这样的。

定义服务时，首先创建一个或多个服务契约(最佳实践是使用接口)。服务契约接口必须用ServiceContract属性标记，服务中使用的每个公开方法都必须标记为OperationContract属性。然后创建实现这些接口的服务类。这样的类可以公开为WCF服务，每个接口(服务契约)都有端点。

没有其他方法有效。您不能添加扩展方法，不能使用泛型或其他任何方法来“扩展”已实现的服务。您可以继承现有的服务类并添加其他接口。显然，这不是一个代码解决方案，除非您创建一些非常高级的代码来在运行时生成动态数据类型(=在运行时发射MSIL )。