最近与一位同事就在 Rails 应用程序中设计和编码模型的不同方法进行的辩论让我了解了 Rails 上下文中的 DCI。
但是，即使在查看了这个示例应用程序之后，我似乎也无法完全理解整个概念。
目前，在编写 Rails 应用程序时，我倾向于或多或少地“按部就班” 。
所以我想问一些事情——
编辑
我想在 RoR 的上下文中进一步扩展我的问题 - 是否建议在 Rails 中的模型和控制器之间进行另一层抽象？它在不同规模的应用程序中有多广泛？
DCI 是一种范式，因此不仅仅是一种设计应用程序的方式。这是一种思考建模和结构化代码的方式。DCI 的重要部分之一是将系统是什么（域模型）和系统做什么（功能）分开。DCI 不是解决与 MVC 相同问题的不同方法，因此您的第一个问题无法真正得到回答。您可以同时使用 MVC 和 DCI，这并非巧合，因为 Trygve Renskaug 是 MVC 和 DCI 之父。他最近在 google 群组“object-composition”上回答了与此类似的问题。
您链接到的示例违反了一些基本思想，例如将角色对上下文保持私有，并且我实际上也找不到单个上下文，但这可能是由于只花费了很短的时间浏览代码。
我自己不了解 RoR，所以我不能给你一个 RoR 的例子，但是如果你去fullOO，你会发现用不同的语言编写的例子，包括 Ruby 和 Marvin，这是为 DCI 设计的第一种语言。
编辑“什么是 DCI”这个问题没有简单的答案，DCI 是一种范式，就像 OOP 是一种范式一样。它们都有相同的根源，回答上述问题就像回答“什么是面向对象编程”一样复杂。由于 DCI 是面向对象的，而所有主要 OO 语言中的 OOP 实际上是面向类而不是面向对象的，事情变得更加复杂。DCI 旨在生成运行时对象之间的交互在编译时在代码中可见的代码，并且更一般地说，试图通过阅读代码更容易地推断运行时行为。网站_我在上面链接到的内容致力于解释 DCI 的全部内容，并列出了多种语言的示例。红宝石就是其中之一
编辑有一本关于 ruby 和 DCI 的书正在出版中。作者在对象组合和洞察力方面非常活跃
对于想知道 DCI 代表什么的人。
DCI 代表Data Context Interaction
DCI的核心是它为开发人员提供的认知工具。我不确定你是否看过所有伟大的James Coplien/Trygve Reenskaug讲座，但我会尝试为任何刚接触这些概念的人提炼它的要点。它是关于将系统行为从系统的交互域对象（数据实体或系统是什么）中移出，并作为一等公民进入行为对象（系统做什么），通过向对象注入功能来调解对象之间的协作在即时用例的上下文中。
想想 BDD。我们对行为进行编码不是跨越许多对象，例如分布在我们与持久层高度耦合的数据对象中的功能微粒，而是在仅为用例（故事）而存在的内聚对象中，并将功能注入和协调这些哑数据对象的交互。就像物理架构的纯粹层一样，缓慢变化的数据对象不会加载它们一直携带的快速变化的功能实现。相反，Ruby 为我们提供了在运行时轻松地将行为注入对象的能力，当/如果仅在用例的上下文中需要时。
作为 ROR 中的一个示例，如果您在一个用例中涉及一个控制器操作，其中有一个事件概率矩阵，其中大多数条目可能仅在一小部分请求中被触发，那么使用不需要为每个可能的数据用例执行每个事件的知识。此外，不必在我的文本编辑器中挖掘 18 个文件来了解交互是如何工作的，而不是将所有逻辑清晰地抽象为上下文对象提供的接口中的模式，这也是一个明确的优势。
关于您关于rails中控制器和模型之间的“另一个”抽象层的问题，我不确定您指的是哪一个。无论如何，是的。无论如何。没问题。设计模式和 Bobs 叔叔的SOLID原则几乎是 OO 设计中普遍接受的最佳实践。这两者都强烈鼓励策略和实现之间松散耦合的抽象。它们都有助于避免罗马帝国毁灭性的灾难性脑残，因为它们提供了一个每个人都能理解的通用框架。对我来说，DCI 提供了相同类型的认知框架，但用于使系统更易于理解和有效处理，这是任何面向对象设计人员的圣杯。
有一本书（目前正在编写中）关于在 Ruby/Rails 中使用 DCI：Clean Ruby。我强烈建议将自己放在通知列表中——我已经阅读了这本书的部分内容，它看起来非常好。
DCI 在 Rails 世界中得到了认可——在过去的 3 个月左右的时间里，有很多关于它的有趣的博客文章。