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的改进:

  1. 清洁地分离系统行为和数据为数据聚合活动提供了许多好处,包括由于域对象的占用空间更小而实现更高性能的实时分析。
  2. 数据对象和行为对象的重用在各个function部门之间更容易,因为他们拥有自己的居住地点,而不是像在系统中的混合数据/行为对象的子集中随机放置一样。
  3. 随着BDD正在成为事实上的敏捷方法,该组织将在这个实践中领先于其他行业,并可能成为其他志同道合的组织的楷模。