DCI - 数据，上下文和交互 - MVC的继承者？

Question

将Data, Context and Interaction (DCI)推广给组织的最佳描述是什么？

它由Trygve Reenskaug的创建者MVC-pattern创建。

它真的是MVC的继承者还是其他模式？它的优点和缺点是什么？

Answer 1

Trygve在https://vimeo.com/8235394

中演示DCI

创建DCI是为了解决面向对象的问题：审查OO代码太难了。

OO中一个用例的代码通常分布在许多类之间。要了解代码的工作原理，还必须了解运行时对象之间的关系。这些关系不是在代码中设置的，它们取决于具体情况。

DCI建议将给定用例的代码从类中分离出来并放入称为上下文的不同工件中。不同类的对象可以在此上下文中建立关系，并参与具有不同角色的交互。

DCI的重点是让OO代码更具可读性！

我就是这样说的。

Answer 2

我得到的印象是，MVC不是后继，而是补充，例如the artima article on DCI中的图5都有。我认为它应该有助于使模型和控制器之间的区别更加清晰，或者可能在控制器的不同部分或模型的不同部分之间。

基本思想似乎是为数据类的特定操作拆分逻辑，并将其移动到traits / mixins / whatever，每个（用户）操作一个。你将拥有许多小块代码，而不是几个大块。此外，听起来添加新的mixin应该比向基类添加功能更“好”。个别行动的代码可能（我认为？）更加分散，但不同行动的代码应该更清楚，明显地分开。

Answer 3

一个好问题和经常出现的问题。简短的回答是，它是基于Kay，Dahl和其他人的OO创始理念而自行设定的范例。它是由Trygve Reenskaug创建的，因为你注意到了几个目标。其中一个目标是使IO操作成为该计划的一等公民。 （不是磁盘操作中的IO，而是两个不同对象之间的所有通信）。 DCI的另一个重要目标是将系统所做的事情（功能/行为）与系统（数据）分开

Answer 4

我认为改进的系统理解对于任何组织来说都是一个巨大的胜利，但你也可以认为DCI是对MVC的改进，因为有以下其他因素：

1. 清晰地分离系统行为和数据为数据聚合活动带来了诸多好处，包括由于域对象占用空间较小而进行的更高效的实时分析。
2. 当功能部门有自己的居住地而不是像在系统中混合数据/行为对象的子集中随机放置的微粒时，数据对象和行为对象的重用更加容易。
3. 随着BDD成为事实上的敏捷方法论，该组织将在这一实践中领先于其他行业，并可能成为其他志同道合组织的榜样。

Answer 5

我完全认为Andrei Alexandrescu在现代C ++设计中采用了基于策略的设计，但是工作水平较低，DCI看起来像是一个带有部分方法的架构（用例驱动设计）。