最近与同事讨论了在Rails应用程序中设计和编码模型的不同方法,使我跨越了DCI in the context of Rails。
然而,即使经过this example application,我似乎也无法围绕整个概念。
目前,在编写Rails应用程序时,我倾向于或多或少地“by the book”。
所以我想问一些事情 -
修改
我想在RoR的上下文中进一步扩展我的问题 - 是否建议使用Rails中的模型和控制器之间的另一个抽象层次?它在不同规模的应用中有多广泛?
答案 0 :(得分:20)
DCI是一种范例,因此不仅仅是设计应用程序的一种方式。这是一种考虑建模和构造代码的方法。 DCI的一个重要部分是保持系统(域模型)和系统(功能)的区别。 DCI并不是解决与MVC相同问题的不同方法,因此您的第一个问题无法得到真正的回答。你可以同时使用MVC和DCI,这不是巧合,因为Trygve Renskaug是MVC和DCI的父亲。他最近在google小组的'object-composition'上回复了similar question。
您链接的示例违反了一些基本概念,例如将角色保持为上下文隐私,我实际上找不到单个上下文,但这可能是因为只花了很短的时间浏览代码。
我不知道RoR我的自我所以我不能给你一个RoR的例子但是如果你去fullOO你会发现用不同语言编写的例子,包括Ruby和Marvin第一种语言DCI。
编辑对于“什么是DCI”这个问题没有简单的答案DCI是一种范例,就像OOP是范例一样。它们都有相同的根源,回答上述问题就像回答“什么是对象定向编程”一样复杂。由于DCI是面向对象的,并且所有主要OO语言中的OOP实际上是面向类的而不是面向对象的,因此事情变得更加复杂。 DCI旨在生成代码,其中运行时对象之间的交互在编译时在代码中可见,并且更一般地说,试图通过阅读代码更容易推断运行时行为。我上面链接的site致力于解释DCI的全部内容,并列出了多种语言的示例。 Ruby就是其中之一
编辑在ruby和DCI上有一个book。作者非常活跃于对象组合和洞察力
答案 1 :(得分:14)
对于那些想知道DCI代表什么的人来说。
DCI代表Data Context Interaction
答案 2 :(得分:8)
DCI的核心是它为开发者提供的认知工具。我不确定你是否看过所有伟大的James Coplien/Trygve Reenskaug讲座,但我会尝试为任何刚接触这些概念的人提炼出它的要点。它是关于将系统行为从系统的交互域对象(数据实体或系统是什么)中移出,并转化为行为对象(系统所做的)作为一级公民,通过向对象注入功能来调解对象之间的协作在即时用例的情况下。
想想BDD。我们编写的行为不是跨多个对象编写的,例如遍布我们的数据对象的功能微粒,这些数据对象高度耦合到持久层,但是在仅为用例(故事)存在的内聚对象中,并且将功能注入和协调这些哑数据对象的相互作用。就像物理架构的层层一样,缓慢变化的数据对象不会随着它们随时携带的快速变化的特征实现而加载。相反,Ruby使我们能够在运行时轻松地将行为注入到对象中(如果需要,仅在用例的上下文中)。
作为ROR中的一个例子,如果你有一个控制器动作涉及一个用例,其中有一个事件概率矩阵,其中大多数条目只能在一小部分请求中被触发,那么实例化一个膨胀行为的网络 - 具有为每个可能的数据用例执行每个事件的知识的重型对象是不必要的。此外,不必在我的文本编辑器中挖掘18个文件来理解这种交互是如何工作的,而将所有逻辑干净地抽象为上下文对象提供的接口中的模式也是一个明确的优点。
关于你在rails中控制器和模型之间的“另一个”抽象层的问题,我不确定你指的是哪一个。无论如何,是的。无论如何。没问题。 Design patterns和Uncle Bobs的SOLID原则是OO设计中普遍接受的最佳实践。这两者都强烈鼓励政策和实施之间松散耦合的抽象。它们都有助于避免罗马帝国拆毁大规模的灾难性大脑转储,因为它们提供了一个人人都能理解的共同框架。对我来说,DCI提供了相同类型的认知框架,但是为了使系统更容易理解和有效处理,这对任何面向对象的设计师来说都是圣杯。
答案 3 :(得分:6)
有一本关于在Ruby / Rails中使用DCI的书(目前正在进行中):Clean Ruby。我强烈建议你把自己放在通知列表上 - 我已经阅读了本书的部分内容,看起来真的很好。
DCI在Rails世界中获得认可 - 在过去的3个月左右,有很多有趣的博客文章。