Question

我是Web / WCF /服务的新手 - 所以请耐心等待：）

我正在尝试分析.NET应用程序中的代码流，但我很难理解在公开服务时使用以下方法的原因：

现在，在应用程序中，我有一个C＃类Lib Pro，它有一个名为“XXX.YYY.Services”的C＃类库项目，其中我有2个文件：

ISomeServiceProviderClass.cs SomeServiceProviderClass.cs

在ISomeServiceProviderClass.cs中，我有以下代码结构：

 [ServiceContract]
    public interface ISomeServiceProviderClass
    {
        [OperationContract]
        int SomeFunc();
    }

然后有 SomeServiceProviderClass.cs类，其定义如下：

public class SomeServiceProviderClass: ISomeServiceProviderClass
{
    public int  SomeFunc()
    {

        /// some code to do the implementation..
    } 
}

这是我的提供者应用程序中的示例服务结构。显然，Consumer应用程序正在使用此服务在其UI层中显示结果。

现在我想知道，有什么需要使用名为ISomeFile.cs的接口，然后是实现此接口的SomeFile.cs？

我猜测其中一个原因可能是在每个实现此接口的类中允许不同类型的实现...... 如果是这种情况，为什么不只有一个SomeServiceClass.cs文件，我在其中有可以在派生类中重写的虚函数？或者为什么不使用具有抽象函数的Abstract类？

Answer 1

线索位于[ServiceContract]中的[OperationContract]和ISomeServiceProviderClas属性中。这些表明ISomeSomeServiceProviderClass正在定义WCF服务合同。

此合同（即接口）可以通过服务器端的代码实现以执行实际操作，而在客户端，它由WCF动态实现，以创建代理，通过网络将呼叫转发到服务器

在这种情况下，您不希望使用抽象类，因为这会限制服务器和客户端对象的实现自由。

Answer 2

在服务中，ISomeServiceProviderClass由您的SomeServiceProviderClass源代码实现。但是，在客户端上，ISomeServiceProviderClass由处理与服务通信的WCF通道类实现。

通过显式接口并不是实现此类透明通信的唯一方式，但它是迄今为止最简单，最干净的方法。

Answer 3

该模式称为“契约优先”，用于从实现中明确地分离代码契约（您可以认为是真的）。 Web服务基于WSDL合同，它基本上是该合同的XML表示形式。

你能否告诉我这个结构背后的原因（ASP.NET中的服务+接口）？

3 个答案: