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