1

我正在做的一个项目需要这样的结构：

{BasePrefix}/Application/{id}/Security/Users/{userId}
{BasePrefix}/Application/{id}/Objects/{objectId}
etc.

Application.svc 最终将成为我的 WCF Web 服务。我试图说服他们这样做：

{BasePrefix}/Security/Application/{id}/Users/{userId}

这将允许我拥有多个 WCF Web 服务，如 Security.svc、Objects.svc 等。

他们仍然希望这一切都在应用程序中，因此我不想将我所有的服务方法都放入一个文件中，而是希望通过功能将其分解并使用部分类将它们全部组合到一个资源中。

我在这里看到了一篇关于如何做到这一点的文章：http ://www.meineck.net/2008/04/wcf-hosting-multiple-wcf-services-as.html

但是，该文章中的开发人员正在使用 Net TCP 绑定，因此我不确定这是否适用于 WebHttpBinding 以及 IIS 将如何处理多个资源。

有人做过吗？我链接的文章是一个很好的资源吗？还是有更好的替代方法来达到相同的结果？

4

1 回答 1

0

链接文章中的方法是合理的，并且适用于netTcpBinding（包括webHttpBinding，wsHttpBinding等等）以外的绑定。

但是，我相信您尝试做的是使用 URL 重写方案（可能使用该UriTemplate属性），这与该文章实际谈论的内容略有不同。它指的是由同一个服务创建和实现多个接口，并将每个接口映射到自己的端点。

该方法不适用于单个端点。因此，如果您的端点是{BasePrefix}/Application，则只能映射到配置中的一个接口（例如IApplicationService）。

在您的情况下，我认为您无法采用多接口路由，因为您只需要一个端点。因此，您仍然需要一个包含所有方法的单一整体接口（丑陋），但理论上您可以使用部分类将这些方法的实现拆分为逻辑组。它更好，但并不完全理想。

您的原始评估走在了正确的轨道上。如果您的方案如下所示：

{BasePrefix}/Security/Application/{id}/Users/{userId}
{BasePrefix}/Repository/Application/{id}/Objects/{objectId}

然后，您将能够使用这两种方法中的任何一种——要么拥有多个服务，要么拥有一个实现多个接口并托管多个端点的服务。

那篇文章中的代码/配置的真正设计目的是使单个服务实例能够托管多个端点。这样做的主要原因是如果您不得不在服务之间复制大量代码。不幸的是，这不是您的目标，因此您要么必须更加努力地推动您提出的 URI 方案，要么处理单一的服务合同（接口）并尽最大努力通过指令和/或部分类来保持实现的清洁。#region

于 2010-04-01T15:03:43.293 回答