情境：
我有几个服务，我希望被不同的客户发现。执行发现是完美的。但是现在我出于不同的原因拥有不同版本的服务。
我的应用程序生命周期中可能有3-4个不同的层：生产，分期，测试和开发。
我需要支持我在过去6个月内部署的客户端，因此我可能需要同时运行2-3个版本的服务。不是合同的不同版本，而是实现的版本略有不同。
我可能还需要按照它们提供的数据类别来分离服务。假设我有一个提供美国数据的服务实例和另一个提供加拿大数据的实例，可能还有提供澳大利亚数据的第三个实例。在某些情况下，该服务可能有多个类别。
因此，从客户的角度来看，如果我要求仅基于合同的服务，我可能会获得9到15个端点，而我真的只想与生产，美国，版本1.1的一个服务进行通信。我知道该服务存在范围，但我无法成功创建一系列范围，这些范围允许我在环境中需要的灵活性。
在前面的示例中，我一直在寻找一种非常具体的服务，但我可能还希望看到针对生产的特定合同的所有服务，无论它们是哪个国家/地区或版本。我可能还需要在混合中添加额外的“范围”。总的来说，我可能有4-6个标准被用作“范围”。
问题：
范围是构建这种复杂过滤的正确方法还是我需要做一些自定义的事情？
如果范围是正确的方法，你可以指出我可以看到的样本吗？
如果我需要自定义是否有一种标准方法来扩展“范围”行为，以便我可以欺骗它做我想做的事情？
源代码：
答案 0 :(得分：4)
是的，范围是可行的方法。我想向你推荐一篇由Juval Lowy撰写的精彩文章Discover a New WCF with Discovery（Programming WCF services书的作者）。以下是使用范围的直接引用：
范围非常有用 自定义发现和添加 对你的复杂行为 应用，特别是在写作时 框架或管理工具。该 范围的经典用法是启用 客户区分 来自不同的多态服务 应用。但是，这是 有点罕见。我发现 范围方便 区分端点类型 相同的申请。
例如，假设给定 合同你有多个 实现。 你有 生产中使用的操作模式 和模拟模式 测试或诊断。使用范围， 客户可以挑选 需要正确的实施类型， 不同的客户从不冲突 消费一个人 另一个人的服务。你也可以 让同一个客户拿起一个 基于的不同端点 调用的上下文。你可以 有剖析的端点， 调试，诊断，测试， 仪器仪表等。
这非常适合您想要解决的问题。
本文还包含有关在配置和代码中声明范围的良好示例。从服务使用者的角度来看，我看到两个选项：如果要在发现阶段过滤服务，可以将FindCriteria实例中所有需要的范围填入DiscoveryClient.Find方法中，或者可以获得所有服务并手动检查其范围。
范围本身是一个Uri对象，所以它可以使用“key = value”表示法在那里放置很多不同的信息。这应该注意“扩展”范围过滤，并不会限制你的前向兼容性。