最近与一位同事就Rails应用程序中设计和编码模型的不同方法进行了一场辩论,这让我跨越了Rails上下文中的DCI。
然而,即使在浏览了此示例应用程序之后,我也无法理解整个概念。
目前,在编写Rails应用程序时,我倾向于或多或少地使用"按书“。
所以有几件事我想问--
编辑
我想在RoR的上下文中进一步扩展我的问题-- Rails中的模型和控制器之间是否有另一层抽象?它在不同规模的应用中有多广泛?
发布于 2012-03-14 09:22:24
DCI是一种范例,因此它不仅仅是一种设计应用程序的方法。这是一种思考建模和构造代码的方法。DCI的一个重要部分是保持系统是什么(域模型)和系统做什么(功能)分开。DCI并不是解决与MVC相同问题的不同方法,所以您的第一个问题无法得到真正的回答。您可以同时使用MVC和DCI,这不是巧合,因为Trygve是MVC和DCI的父亲。最近,他在google小组“对象-组合”上回答了一个相似问题的问题。
您所链接的示例违反了一些基本思想,例如将角色与上下文保持私有关系,我实际上也找不到一个上下文,但这可能是因为只花了很短的时间浏览代码。
我不知道RoR自己,所以我不能给您一个RoR示例,但是如果您去fullOO,您会发现用不同语言编写的示例,包括为DCI设计的第一语言Ruby。
编辑没有简单的回答“何谓DCI”DCI是一个范例,就像OOP是一个范例一样。它们都有相同的根源,回答上面的问题就像回答“什么是面向对象的编程”一样复杂。更复杂的是,DCI是面向对象的,而在所有主要的OO语言中,OOP实际上是面向类的,而不是面向对象的。DCI的目标是生成代码,其中运行时的对象之间的交互在编译时代码中是可见的,并且在更一般的条件下,试图通过读取代码来更容易地推理运行时行为。我所链接到的站点致力于解释DCI的全部内容,并列举了许多语言中的示例。露比就是其中之一
编辑,红宝石上有一个书,而DCI在路上。作者对对象构图相当活跃,洞察力很强。
发布于 2014-03-09 01:23:55
对于那些想知道DCI代表什么的人来说。
DCI代表Data Context Interaction
发布于 2012-05-12 02:38:50
DCI的核心是它为开发人员提供的认知工具。我不确定你是否看过所有伟大的James Coplien/Trygve Reenskaug讲座,但我将尝试为任何新概念的人提炼它的要点。它是将系统行为从系统的交互域对象(数据实体,或系统是什么)中移出,并作为第一类公民(系统所做的)移动到行为对象(系统所做的)中,通过在用例上下文中及时注入功能来调解对象之间的协作。
想想BDD吧。我们编写的行为不跨越许多对象,比如分散在数据对象上的功能微粒,这些对象高度耦合到持久层,而是在仅为用例(故事)存在的内聚对象中编码,这些对象向这些哑数据对象注入功能并协调它们之间的交互。就像物理体系结构的纯粹层一样,缓慢变化的数据对象没有加载它们一直随身携带的快速变化的特性实现。相反,Ruby为我们提供了在运行时(如果需要的话)仅在用例上下文中很容易地将行为注入对象的能力。
作为ROR中的一个例子,如果在一个用例中包含了一个控制器操作,其中有一个事件概率矩阵,其中大多数条目可能只在一小部分请求中被触发,那么实例化一个臃肿的行为网络--具有对数据的每一个可能用例执行每个事件的知识的重对象是不必要的。另外,不需要在我的文本编辑器中挖掘18个文件来理解交互是如何工作的,而将所有的逻辑清晰地抽象到上下文对象提供的接口中的模式也是一个肯定的优点。
关于rails中控制器和模型之间“另一个”抽象层的问题,我不确定您指的是哪一个。不管怎样,是的。千方百计。没问题。设计模式和Bobs叔叔的实心原则几乎是OO设计中普遍接受的最佳实践。这两种方法都强烈鼓励在策略和实现之间进行松散耦合的抽象。它们都有助于避免罗马帝国灾难性的大脑垃圾场摧毁震级,因为它们提供了每个人都能理解的共同框架。对我来说,DCI提供了相同类型的认知框架,但是为了使系统更容易理解和有效地处理,这对于任何面向对象的设计师来说都是圣杯。
https://stackoverflow.com/questions/9677916
复制相似问题