我已经看到了关于这种模式的一些问题，但我试图深入了解这种设计模式。在这方面的任何资源，专家评论他们倾向于使用这种模式的场景以及要避免的场景和一些现实世界的例子在这方面将是非常有用的。 我不是在寻找什么是COR类型，而是来自专家的一些高级评论。这将有助于我在下次更负责任地应用这种模式。
答案 0 :(得分：2)
好的，就在最近，我在实际的企业开发中有了一些这种模式的经验。
在我们的系统中，我们有不同级别的存储（按优先顺序排列）：基础，产品特定和用户特定。每个存储都拥有一组XML文件，这些文件在元语言中描述了要在网页上显示的元素。每个XML文件描述了要显示的整个页面。
当用户尝试导航到网页时，我们的系统会在页面ID方面对必要的XML文件存储进行查找。
当找到必要的文件时，查找结束，没有预期的合并算法（完全没有层之间的合并）。
因此，对于这种特殊情况，我们引入了一个带有1个方法的接口（伪代码）：
ViewMetadata GetViewMetadata(string viewId);
我们只是构建了一个存储链 - 这个接口的实现者。负责从XML视图元数据构建实际HTML表示的HttpHandler（用于Asp.Net用例）具有查找机制的唯一入口点：所提到的接口实现者的实例。
一切似乎都没问题（实际上是几个月）。的但
新要求来了。此要求与“促销”有关：在某些情况下（“促销工作流程”）的XML文件必须从用户存储转移到产品存储。
实际上由于我们过于抽象的查找机制实现，我们无法处理这个要求 - 整个存储链的处理程序只有一个抽象入口点。
因此，我们拒绝了此要求的CoR模式。现在，实际的处理程序具有对所有3个存储的显式引用，并且当“使用wiew Id = X提升视图”请求时，它只是直接从用户存储获取元数据并将元数据保存到产品存储。
因此，作为一个底线，我可以说当你对链元素的显式交互有一些要求时，CoR模式不是一个出色的解决方案。 CoR“HandleRequest（）”的抽象界面太过让您只有机会与链的入口点进行交互。
顺便说一下，这是一个保存基于CoR的实施的机会，但问题实际上是关于努力和可维护性:)