WCF 常用参数 ClientMessageInspector、DispatchMessageInspector 还是替代方案？

Question

我仅将 WCF 用于数据服务（即应用程序内部并且非常精简，没有会话状态等），以保持我们的 Web 应用程序可扩展。

我们需要为当前一直传入的每个服务调用提供一些通用属性。每次调用都只有一个请求对象并不理想，因为除了这些常见属性之外，其余的都非常多样化，并且在开发过程中变化非常频繁。

目前我正在考虑使用自定义标头和 clientmessageinspector 来设置值。 对于这种情况，这是最简单的推荐方法还是有更好的方法？

更多细节..

下面的红点是我不确定正确方法（或如何去做）的地方。

发送的内容

发送的数据是一组简单的 id（3 或 4 个用于 userid、clientid 等） - 所有这些 id 都会影响安全性和性能（在某些情况下，它决定了要转到哪个数据库）。

我们还将对其进行扩展，使其拥有更复杂的权限 - Windows 工作人员不需要。

调用者可以是来自会话对象的 Web 应用程序，也可以是手动填充这些对象的 Windows 服务工作者。

当前的想法

理想情况下，调用者工作流上的 getinstance 将使用会话对象自动填充这些属性，或者使用 Windows 服务调用（不同的构造函数？）手动填充这些属性。

然后，我们将确保这些参数始终可用，无需任何思考，也无需在整个代码中不断引用，以在调用它的每个函数上构造合约。我们目前有很多服务调用（由于应用程序的规模/复杂性，而不是由于糟糕的工程:)），因此随着复杂权限的扩展，以自我记录的方式执行规则变得有点困难。

从概念上讲，会话是您在应用程序中处理此问题的地方，但服务实际上只是一个数据访问层（具有视图映射、分页和来自存储库调用的最后调用安全性），因此我们不需要它某种重复或复杂性，只是要包含在查询中的关键身份和权限字段。

问题

这感觉很像我们应该在调用的标头上做的事情，因为我们总是需要这些字段，但我有点不确定 set 和 get 应该位于端点和客户端接口的生命周期中的哪个位置.我也很高兴我错了。

Answer 1

根据我使用消息检查器的经验，最初设置和配置可能非常棘手，并且在我的研究中没有涵盖所有内容的网站，我不得不从几个不同的地方挑选 sn-ps 并将它们拼凑在一起。

您需要质疑您在标题中添加的内容。是被调用的方法需要使用的信息吗？如果是这样，那么将它放在标题中是错误的选择，因为每个方法都需要将信息解析出来。

最适合这种情况的信息是自定义身份验证和/或与 WCF 调用相关的用户特定元数据。在我的情况下，我有一个由自动化服务发起的 WCF 调用，该调用被中继到进一步的 WCF 端点，这是使用消息检查器的理想场景，因为我能够将元数据添加到中继点的标头以供后续使用终点。

如果您只是想打包每个调用共有的一些数据，那么我将包括创建一个具有适当属性的基本数据对象，然后将其扩展为更专业的调用（端点可以确保该公共数据要么存在，要么假设一些默认值（如果不存在）。对于每个端点所需的公共数据，使用消息检查器是多余的，并且可能不可行。

Answer 2

这可能是一种较旧的方法，但您可以轻松地从System.Runtime.Remoting.Messaging 中利用CallContext。客户端可以使用IClientMessageInspector 的实现来设置操作调用的调用上下文，并在服务器上使用IMessageInspector 的实现来从CallContext 中检索共享数据。

Answer 3

我应用了类似的架构；基本上每个客户端调用都需要携带一些关于选择哪个数据库的信息，一个标识符等。在服务器端，这些参数会自动处理并存储在字典中。

我创建了一个通用代理类来包装客户端代理，以便为每个服务调用添加相关的标头。每个需要调用服务的开发人员都在他们的调用中使用了这个通用代理类。

在服务端，我实现了DispatchMessageInspector 作为端点行为，其中数据从请求标头中提取并存储在字典中。字典在 OperationContext (IExtension<OperationContext>) 的扩展中初始化，并且在请求处理期间可用。

注意服务的实例上下文模式为PerCall。