向组织推销数据、上下文和交互 (DCI)的最佳描述是什么?
它由MVC 模式的创建者Trygve Reenskaug创建。
它真的是 MVC 的继承者还是只是另一种模式?它的优点和缺点是什么?
Trygve 在https://vimeo.com/8235394中介绍了 DCI
创建 DCI 是为了解决面向对象的问题:审查 OO 代码太难了。
OO 中一个用例的代码通常分布在许多类之间。要了解代码的工作原理,您还必须了解运行时对象之间的关系。这些关系不是在代码中设置的,它们取决于情况。
DCI 建议将给定用例的代码从类中分离出来并放入称为上下文的不同工件中。不同类的对象可以在此上下文中建立关系,并在它们具有不同角色的情况下参与交互。
DCI 的全部意义在于使 OO 代码更具可读性!
我就是这样推销它的。
我得到的印象是,它与其说是 MVC的继承者,不如说是一种补充,例如关于 DCI 的 artima 文章中的图 5两者都有。我认为它应该有助于使模型和控制器之间的区别更加清晰,或者可能在控制器的不同部分或模型的不同部分之间进行区分。
基本思想似乎是为您的数据类中的特定操作拆分逻辑,并将其移动到特征/混合/无论如何,每个(用户)操作一个。您将拥有许多小段代码,而不是几段大段。此外,听起来添加新的 mixins 应该比向基类添加功能“更好”。单个动作的代码可能(我认为?)更加分散,但不同动作的代码应该更加清晰和明显地分开。
一个好问题和一个经常出现的问题。简短的回答是,它本身就是基于 Kay、Dahl 和其他人的 OO 创始思想的范例。正如您所注意到的,它是由 Trygve Reenskaug 创建的,并考虑了几个目标。其中一个目标是使 IO 操作成为该计划的一等公民。(不是磁盘操作中的 IO,而是两个不同对象之间的所有通信)。DCI 的另一个重要目标是将系统的功能(功能/行为)与系统的功能(数据)分开
我认为改进的系统理解对任何组织来说都是一个巨大的胜利,但是由于以下其他因素,您也可以证明 DCI 是对 MVC 的改进:
在我看来,它完全是 Andrei Alexandrescu 在现代 C++ 设计中的基于策略的设计,但是这项工作更底层,DCI 看起来像一个带有部分方法的架构(用例驱动设计)。