【问题标题】:Calling WCF Services in ASP.NET MVC application在 ASP.NET MVC 应用程序中调用 WCF 服务
【发布时间】:2013-11-12 19:51:03
【问题描述】:

我需要从 ASP.NET MVC 应用程序调用 WCF 服务。设计 ASP.NET MVC 和 WCF 服务通信的更好方法是什么?

  1. 控制器保留对 WCF 服务的引用,并在需要时调用服务方法。

  2. Controller 使用 DI 容器,例如统一解析 WCF 服务实例。它仍在控制器类中完成。

  3. 创建一个专门用于与 WCF 服务通信的服务中介类。控制器调用中介类。

当一个服务被多个控制器使用并且一个控制器可能调用多个服务时,考虑一个相当复杂的场景

【问题讨论】:

  • 你在多少个地方进行 WCF 调用(或重用逻辑)?如果它在一个控制器中,就在那里做。如果您发现自己重复执行相同的调用,则将其拆分为中间服务。保持您的代码“干燥”。
  • 您可以在您的项目中添加服务层,您可以在其中实现所有WCF服务操作并实现该层的抽象视图,以便客户端类处理抽象视图...

标签: c# asp.net-mvc wcf asp.net-mvc-4


【解决方案1】:

鉴于该服务被多个控制器使用,我认为创建一个服务层将是最佳选择。 将 WCF 实现抽象到服务层提供了独立单元测试服务层和控制器操作的灵活性。 还保持控制器独立于服务更改。

【讨论】:

    【解决方案2】:

    控制器可以将您在生成客户端代理时获得的 ServiceContract 接口作为构造函数参数。然后指示您的 DI 框架将适当的实例注入其中(这将是实现服务合同接口的代理)。

    所以基本上你的应用程序有一个服务层,它被抽象在一个接口(服务契约)后面,但它的实现位于其他地方(在远程 WCF 服务中)。

    恕我直言,您不需要创建服务中介类,除非您的 WCF 服务逻辑对于您的 Web 应用程序来说当然是不够的,并且您需要将更多的业务逻辑放入其中。在这种情况下,调解员可以提供帮助。

    【讨论】:

    • 我同意。在大多数情况下,对服务接口(契约)进行编程并通过 DI 框架注入具体的依赖关系就足够了。
    【解决方案3】:

    此外,服务中介类甚至可以将消费者与服务完全分离(甚至是接口)。可以在不影响客户端的情况下更改服务合同和实现(例如合同方法名称)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-10-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多