为什么将 WCF 用于内联网服务?



我有一个新项目正在做。 该项目的目的是集中所有服务调用,并为其他服务提供单一入口点。

目前,开发人员调用大约 5 种不同的服务来从内部的不同来源获取数据。

该项目将创建一个服务,公司中的其他开发人员可以使用该服务从单个服务调用所有这 5 个不同的服务。

我的问题是

我应该使用 Web API(RESTful)还是 WCF(基于 SOAP)构建服务?

我的经理建议我使用一种宁静的方法来创建这项服务。但是,由于此服务在公司内部使用,因此我认为 WCF 将是一种更合适的方法,因为 WSDL,您可以使用它来创建代理类并使用对象,而不是客户端分析返回的数据。

此外,WCF 是操作驱动的,Web API 是资源驱动的。

何时使用行动驱动模型,何时使用资源驱动模型?

如果您能深入了解我的情况并帮助我决定将哪种方法应用于我的项目,我将不胜感激。

这是我到目前为止所拥有的,但仍然不足以说服我使用其中一个。

周转基金

  1. 基于 SOAP 的服务
  2. 多种传输协议(HTTP、TCP、UDP 等)
  3. 用于创建代理的 WSDL(生成类型安全的绑定程序类/对象)
  4. 它允许客户端像类库一样引用服务终结点,这意味着您不会在桌面客户端中处理 XML 或 JSON。您正在使用类和对象。
  5. 与 Web API 相比,开销更大
  6. 内部/内联网
  7. 操作驱动模型,专注于服务能够执行的操作
  8. WCFExtras+ 用于记录服务

网络接口

  1. 休息服务
  2. 基于 HTTP(一等公民)
  3. 多种媒体类型(XML、JSON)
  4. 重量 轻
  5. 没有 WSDL(通常客户端最终会自己解析数据)
  6. 公共 API(各种客户端)
  7. 资源驱动的体系结构,基于对象而不是函数公开终结点
  8. 客户端互操作性
  9. ASP.NET 使用 Swagger 的 Web API 帮助页面

更新:

我的问题是理解为什么WCF应该用于内部网应用程序。 是因为 WSDL,它自动为您创建代理类和 Web API,您必须在客户端做更多工作来解析返回的 XML 或 JSON?

要考虑的一个因素是现有服务代码是否"内置"到现有服务中。几年来,当我创建新服务时,所有代码都是 WCF 服务应用程序的一部分。这似乎是权宜之计,但却是短视的。

如果应用程序组件内置到它们自己的库中,然后可以通过 WCF 服务或 Web API 公开该库,那就更好了。如果它是这样构建的,那么做一个,另一个,改变主意,或者两者兼而有之要容易得多。

我倾向于 Web API,因为 1) 任何客户端都更容易使用它,2) 现在每个人似乎都专注于 Web API,这是构建经验的好领域。

对于内部使用的 API,我有一种方法可以为我提供一些与 WCF 服务相同的好处。

  • "服务"是独立于 API 的库。它只是一个类库,我可以独立于 API 进行测试。
  • 我在单独的库中为 API 及其模型创建了一个接口
  • 我需要创建自己的客户端代码来测试 API,因此我创建了一个实现服务接口的可重用 HTTP 客户端。其他开发人员不需要使用它,但如果他们愿意,他们可以添加该接口和我现有的客户端。这样,他们就可以不用编写和测试自己的客户端代码,而是已经完成并测试过一些东西。它们还有一个单独的接口和实现,便于依赖注入。
  • 这可能有点矫枉过正,但我让我的 API 实现相同的服务接口。这样,如果我在开发过程中修改接口(而不是谈论对已发布接口的重大更改),就很容易看到我需要在哪里更新 API、客户端等。

这为使用内部客户端提供了一些便利。缺点是,它可能与开发 RESTful API 的最佳实践"脱节"。

IMO 关键是逻辑与 API 或 WCF 之间的功能分离。如果您以一种方式构建 API,然后想要做一些不同的事情,那么您可以专注于它的这一端,而不必重写或重新测试代码中更重要的部分。

最新更新