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