DCI - 数据、上下文和交互 - MVC 的继承者？
对数据、背景和交互 (DCI) 的最佳描述是什么？到一个组织？
它由 Trygve Reenskaug 创建，他是 MVC 模式。
它真的是 MVC 的继承者还是只是另一种模式？ 它的优点和缺点是什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
对数据、背景和交互 (DCI) 的最佳描述是什么？到一个组织？
它由 Trygve Reenskaug 创建，他是 MVC 模式。
它真的是 MVC 的继承者还是只是另一种模式？ 它的优点和缺点是什么？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
Trygve 在 https://vimeo.com/8235394 中介绍了
DCI DCI 的创建是为了解决问题面向对象：审查 OO 代码太困难了。
面向对象中一个用例的代码通常分布在许多类中。 要理解代码的工作原理，您还必须了解运行时对象之间的关系。 这些关系不是在代码中设置的，它们取决于具体情况。
DCI 的建议是将给定用例的代码从类中分离出来，并放入称为上下文的不同工件中。 不同类的对象可以在此上下文中建立关系并参与具有不同角色的交互。
DCI 的全部意义在于使 OO 代码更具可读性！
这就是我的推销方式。
Trygve makes a presentation of DCI in https://vimeo.com/8235394
DCI has been created to solve a problem in object orientation: it's too difficult to review OO code.
The code for one use-case in OO is typicall spread out between lots of classes. To understand how the code works, you must also know the relationships between objects in runtime. These relationships aren't set in code, they depend on the situation.
What DCI proposes is that code for a given use-case is separated out from the classes and put into a different artifact called context. Objects of different classes can enter into a relationship in this context and take part in interaction where they have different roles.
The whole point of DCI is to make OO code more readable!
That's how I would pitch it.
我的印象是，与其说它是 MVC 的继承者，不如说是补充，例如 关于 DCI 的 artima 文章 两者都有。 我认为它应该有助于使模型和控制器之间的区别更加清晰，或者控制器的不同部分或模型的不同部分之间的区别。
基本思想似乎是分割数据类中特定操作的逻辑，并将其移动到特征/混合/无论什么，每个（用户）操作一个。 您将拥有许多小代码片段，而不是一些大代码片段。 另外，听起来添加新的 mixin 应该比向基类添加功能“更好”。 各个操作的代码可能（我认为？）会更加分散，但是不同操作的代码应该更加清晰和明显地分开。
The impression I got is that it's not a successor to MVC so much as a complement, for example figure 5 in the artima article on DCI has both. I think it's supposed to help make the distinction between model and controller more sane, or maybe between different part of the controller or different parts of the model.
The basic idea seems to be to split logic for particular actions our of your data classes and move it to traits/mixins/whatever, one per (user) action. You'll have many small pieces of code, instead of a few large pieces. Also, it sounds like adding new mixins is supposed to be "better" than adding functionality to your base classes. The code for individual actions will probably (I think?) be more spread out, but code for different actions should be more clearly and obviously separated.
一个好问题，也是一个经常出现的问题。 简而言之，它本身就是一个基于 Kay、Dahl 等人的 OO 创始思想的范例。 正如您所注意到的，它是由 Trygve Reenskaug 创建的，其中考虑了几个目标。 其中之一的目标是使信息战操作成为该计划的一等公民。 （不是磁盘操作中的 IO，而是两个不同对象之间的所有通信）。 DCI 的另一个重要目标是将系统的功能（功能/行为）与系统的本质（数据）分开
A good question and an often occurring question. The short answer is that it's a paradigm on it's own based upon the founding ideas of OO by Kay, Dahl and others. It was created by Trygve Reenskaug as you note with several goals in mind. One of them being tha aim of making IO operations first class citizens of the program. (not IO as in disk operations but all communication between two different objects). Another important goal of DCI is to split what the system does (functionality/behavior) from what the system is (data)
我认为改进的系统理解对于任何组织来说都是一个巨大的胜利，但您也可以认为 DCI 是 MVC 的改进，因为以下附加因素：
I think improved system comprehension is a huge win for any organization, but you could also make the case that DCI is an improvement on MVC due to the following additional factors:
在我看来，它完全是 Andrei Alexandrescu 在现代 C++ 设计中基于策略的设计，但是这项工作水平较低，DCI 看起来像是一个具有部分方法论的架构（用例驱动设计）。
It totally looks to me as the Policy based design by Andrei Alexandrescu in Modern C++ design, however that work is more low level, DCI looks like an architecture with parts of methodology (use cases drive the design).