没有服务合同接口的 WCF 是可能的答案

【问题标题】：WCF without service contract interface is possible没有服务合同接口的 WCF 是可能的
【发布时间】：2014-04-09 19:31:39
【问题描述】：

我在谷歌上搜索知道我们如何轻松地将 asmx 服务转换为 wcf，我看到人们编写类似的代码

这是我的旧 asmx 服务

[WebService(Namespace="http://kennyw.com/sampleservices/")]
public class MyService : System.Web.Services.WebService
 { 
[WebMethod]
public string Hello(string name)
  { 
   return string.Format(“Hello {0}.”, name);

  }

}

转换为 wcf

[ServiceContract(Namespace="http://kennyw.com/WCFservices/")]
[WebService(Namespace="http://kennyw.com/sampleservices/")]
public class MyService : System.Web.Services.WebService
 { 
[WebMethod]
[OperationContract]
public string Hello(string name)
   { 
    return string.Format(“Hello {0}.”, name);

   }

}

我在转换时看到人们没有使用服务合同接口。它将如何工作，因为我知道当我们开发 wcf 服务时，我必须为单个服务编写一个服务合同接口。所以寻找讨论如何在没有服务合同接口的情况下开发 wcf 服务。谢谢

【问题讨论】：

有点不清楚你在问什么。您不必必须编写单独的接口，但这是可测试性和可重用性的好习惯。
Why does .net WCF Service require the Interface 的可能重复项
嗯...它编译了吗？这行得通吗？
如果有问题，您可以将其转换为 ASP.NET Web API 服务。

标签： c# web-services wcf servicecontract

【解决方案1】：

如果您没有在 web.config 中指定正确的合同命名，上述方法将不起作用。

如果您没有接口的类位于以下命名空间中：

namespace Foo
{
    [ServiceContract(Namespace="http://kennyw.com/WCFservices/")]
    [WebService(Namespace="http://kennyw.com/sampleservices/")]
    public class MyService : System.Web.Services.WebService
    { 
        [WebMethod]
        [OperationContract]
        public string Hello(string name)
        { 
            return string.Format(“Hello {0}.”, name);

        }
    }
}

在这种情况下，Web config 服务配置应如下所示

<services>
    <service name="YourServiceName">
        <endpoint address="" behaviorConfiguration="httpBehavior" binding="webHttpBinding" contract="Foo.MyService"/>
    </service>
</services>

【讨论】：

我只是想知道如果没有服务契约作为接口，上述服务将如何运行。在这里你为服务合同指定一个类名。因此，当我们可以编写没有服务合同接口的 wcf 服务时，为什么人们将接口用作服务合同。我正在寻找为什么人们使用接口作为服务合同的所有有效点？

【解决方案2】：

因为针对接口进行编程是一件好事，原因如下：

例如，其中一个非常重要的原因是您可以轻松地在单元测试中使用它，从而可以轻松地模拟或存根它（并对其设定期望）。

IYourInterfaceMethods 存根 = MockRepository.GenerateStub();

IYourInterfaceMethods mock = MockRepository.GenerateMock();

如果您在大公司工作，当您不只是为自己编写代码并完成 JIRA 任务时，您通常可以为他人、为您的大学编写程序。您正在为他们创建 API，他们可以使用和重用这些 API（从而降低公司的成本）。在这种情况下，您应该将服务的实现放在一个单独的库中，只公开他们可以调用的接口，并重用您的主件。但是在这种情况下发生的情况是，当某人开始使用您的服务时（例如可以发送 SMS，这需要花钱，或者例如运行 5 分钟长的一些复杂计算的处理），他将需要能够如果他想对其进行单元测试，请模拟或存根它。所以你的代码必须是可测试的，你可以通过接口暴露你的功能来实现它。这样，您的 API 用户就可以使用不花钱的简单框架（因为您仍然可以使用不需要使用接口的其他单元测试框架，但它们不是免费的）。

如果您将接口放入单独的库中，则 API 的用户只能拥有该库以及他们使用的接口。如果你的界面是稳定的（不要经常改变），他们不需要重新编译他们的代码，也很少需要重新部署他们的应用程序（移动、网络等）。在大公司中，部署新版本可能很危险。他们喜欢坚持一个黄金计划：如果它没有被破坏，就不要修复它。对您有什么好处？您可以随心所欲地使用具体的实现，修复错误，修复这个和那个，重构，删除......总的来说很有趣，但不会伤害任何人:)......
还有很多其他原因使用接口，程序员的安全等。但我认为以上是最重要的2。

希望我能帮上忙。

【讨论】：