DCI – 数据，上下文和交互 – MVC的后继者？
数据，上下文和交互（DCI）的最佳描述是什么？
它由MVC模式的创build者Trygve Reenskaug创build。
它真的是MVC的inheritance者还是另一种模式？ 它有什么优点和缺点？
我得到的印象是它不是MVC的inheritance者 ，而是一个补充 ，例如在DCI的artima文章中的图5就有这两个。 我认为它应该有助于区分模型和控制器更为理智，或者可能在控制器的不同部分或模型的不同部分之间。
基本的想法似乎是将您的数据类的特定操作的逻辑分开，并将其移动到traits / mixins /无论哪一个（用户）操作。 你将会有许多小块的代码，而不是几个大块。 另外，这听起来像添加新的mixin应该比向您的基类添加function“更好”。 个人行为的代码可能（我认为？）更加分散，但不同行为的代码应该更清楚明显地分开。
Trygve在http://oredev.org/videos/dci–re-thinking-the-foundations-of-oo中介绍DCI
创buildDCI是为了解决面向对象方面的问题：检查OO代码太困难了。
OO中的一个用例代码通常分布在许多类之间。 为了理解代码如何工作，您还必须知道运行时对象之间的关系。 这些关系不是在代码中设置的，它们取决于情况。
DCI提出的是给定用例的代码从类中分离出来，并放入一个不同的称为上下文的工件。 不同类别的对象可以在这种情况下进入一个关系，并参与他们有不同angular色的交互。
DCI的重点在于使OO代码更具可读性！
我就是这样想的
一个好问题和一个经常发生的问题。 简单的回答是，这是一个基于凯，达尔等人的面向对象创始思想的范式。 它是由Trygve Reenskaug创build的，正如你注意到几个目标一样。 其中之一就是要使IO运营项目的头等公民成为可能。 （不像磁盘操作那样是IO，而是两个不同对象之间的所有通信）。 DCI的另一个重要目标是将系统所做的事情（function/行为）与系统（数据）
在现代C ++devise中，Andrei Alexandrescu完全把我看作是基于策略的devise，然而这个工作比较低级，DCI看起来像是一个包含方法部分（用例驱动devise）的架构。
我认为提高系统理解对于任何组织来说都是一个巨大的胜利，但是由于以下附加因素，您也可以提出DCI是对MVC的改进：
- 清洁地分离系统行为和数据为数据聚合活动提供了许多好处，包括由于域对象的占用空间更小而实现更高性能的实时分析。
- 数据对象和行为对象的重用在各个function部门之间更容易，因为他们拥有自己的居住地点，而不是像在系统中的混合数据/行为对象的子集中随机放置一样。
- 随着BDD正在成为事实上的敏捷方法，该组织将在这个实践中领先于其他行业，并可能成为其他志同道合的组织的楷模。
