关于将Jdon框架提升为DCI框架的设想
在]Jdon框架 6.4案例中(这里),我使用Domain Events实现了一种DCI,Domain Events和DCI是两种不同角度看同一个问题,而DCI是从软件分析如彩色UML四色原型直接映射过来的,因此让开发者直接和DCI打交道,能够减少不必要的转换翻译失真。
那么我的设想是将Domain Events作为DCI底层机制,层层封装,Dirsruptor--->Domain Events ---> DCI,DCI是最高级别的层次。
另外也看到Ruby领域正在构想DCI模式或框架,他们遇到一些关于场景的问题,文章:DCI patterns - how to write DCI contexts in Ruby
应用对象是否应该知道场景?
Should the application object (a model) know about the contexts?
有三个选择:
1. 应用对象可以访问所有可能场景,MVC的控制器只要这样调用: application.register_new_user(..) ,是应用进行场景初始化。
2.应用有能力知道全局性场景: NewUserContext.new(..).
3.控制器消失(正如Rails, banq注:JdonFramework也是), 控制器和场景的匹配是在一个配置文件中。
该文最后说:到目前为止,所有的Ruby 的DCI的例子似乎有点冗长。这是因为DCI并不能直接翻译到如Ruby这样的动态语言。
现在,我们在jdonFramework中使用“事件”翻译DCI到Java中,这个路子虽然有点绕,但是只要把其封装起来,让开发者直接面对DCI,也许是一条办法。
下面的问题是如该文提出的三个选择,我个人比较倾向于消灭MVC,见:MVC已死。用DCI场景替代MVC的控制器,用REST URL替代控制器与页面交互,这样消灭了控制器,就是消灭了MVC。
因为@oojdon 已经开发了一个开源框架JdonMVC, 我注意到其中有@Context标注,所以,也许我们在JdonMVC的REST上加工一下, 消灭MVC的DCI框架就可能探囊可取了。
有兴趣者可讨论一下可能性。
[该贴被banq于2011-09-13 12:17修改过]
[该贴被banq于2011-09-13 12:19修改过]
[该贴被banq于2011-09-13 12:20修改过]
[该贴被banq于2011-09-13 12:27修改过]