Question

我正在研究的项目需要这样的结构：

{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等。

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

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

有人这样做过吗？这篇文章我链接了一个很好的资源吗？或者是否有更好的替代方法来实现相同的结果？

Answer 1

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

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

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

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

您的原始评估是在正确的轨道上。如果您的计划如下：

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

然后您就可以使用其中一种方法 - 要么拥有多个服务，要么拥有一个实现多个接口并托管多个端点的服务。

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