2010年04月11日 22:31 "taochenpfj"的内容
最近一直在考虑脱离了关系型数据库,到底如何存储?
看了那些文章和评论自己还是迷茫,唉。。。。归根结底还是没用心去研究啊,再说了公司内部对NoSQL也没人了解,头大

兄弟们多拍点砖头,我想再清醒点。。。。 ...

是极,目前我也在这上面徘徊。老套的做着EJB的项目 就是对这些新的东西 无从下手 前些天在翻 BANQ大哥的JDON 获益不浅。就是感觉进度太慢。

强烈希望BANQ大哥能领个简单的入门。

新版本的java ee貌似开始支持介于request和session之间的东东,好像在webbeans标准里含的

个人觉得Context对象跟Role类似,就是对象处理不同角色(场景)时的表现.

2010年04月15日 09:23 "freeren"的内容
人觉得Context对象跟Role类似,就是对象处理不同角色(场景)时的表现 ...

呵呵,可能有些不太相同,我的理解是:

就象戏剧演出,戏剧讲的是一个故事story,软件的需求也是一个story,戏剧需要有角色 宰相 皇帝,戏剧中有场景,比如皇宫场景,可以演绎宰相和皇帝的对话和动作,交互行为角色皇帝的动作,皇帝这个角色是由XXX人扮演,软件中的角色是由某个实体对象来扮演。有时你只有在特定场景才是某个角色,然后才有某个行为。

场景需要有实体扮演的角色参与,需要有相应的交互行为才是完整场景。

我个人体会,充分理解了 四色原型的分析思路后,对角色 场景比较容易理解些。

其实在DCI之前,MVC控制器或SOA的web服务就是场景,只不过从不同角度来称谓,控制器是从前后交互控制角度来称谓,实际上,前后交互就是场景的发生地,就象以前敦煌,它是东西方交汇的地方,那么它就是贸易场景发生的地方,来自不同方向的对象在这里进行交互。

WEB服务也是这个概念,服务是从外部来称谓,为别人提供服务的,我们知道,服务不是一成不变的东西,而是和时间有关,和具体客户要求有关的一种活动,以敦煌为例子,中国人在那里办个旅馆,提供住宿服务,外国人其他人来享受住宿服务,也就是一个预定住宿 付钱 入住等场景发生的地方,在这个住宿服务为目的的场景中,中国人扮演主人,外国人扮演住客,这两个角色有关住宿发生各种行为和结果。

那么,既然DCI和MVC和Web服务都那么相同,为什么要替代它,那是因为DCI的场景抓住了业务本质,而其他两个称谓都是围着鼓边敲鼓,具体实施起来,当然没有DCI能够更贴近需求了。
[该贴被banq于2010-04-15 13:56修改过]

是不是稍微有点激进阿
看技术除了技术本身还要考虑社会因素阿
不知道有哪个大型系统用Qi4j做的,需要成功案例

关注中......

banq,你的《JAVA实用系统开发指南》一书是不是太过时了,里面好多用EJB2做的案例,因为我本人没接触过EJB2,也没用EJB做过任何项目,用的最多的还是spring+hibernate+struts,能把那些项目用EJB3重新发布一下吗?谢谢。我一直把你的作品和框架当java领域的圣经在读,虽然有很多读不懂,但会坚持下去,我相信总会一天我会看懂你写很多知识

哪有死不死这么一说,只是模式的一个进化罢了

MVC这个开发模式,也限制了很多人的思维。

thesecondbull
说的深刻,有见地;
但人处于混沌社会中,必然要归属于一个派别,排除其他,才可理清自己,定义清晰规则;

混沌和规则相生相克,并无对错,所以已悟道的人都出家去了...

NoSQL 不是No SQL,而应该解读成NOSQL-NO ONLY SQL。

目前的Key-Value组成的内存型数据库,不能很好的完成复杂的功能。至少不支持JOIN等SQL语义。

楼主不应该说是新的东西,在Oracle的Ten times系统中早就有了,我认为他就是一种NOSQL。

项目是一个团队组织的形式,不可能都追求新。对“新”的理解,我有几个看法:

第一、所谓新技术是解决以前的弊端,提高生产力,可是带了不确定因素。比如系统的稳定性。

第二、不是所有的新技术都应该采纳,正如第一点所诉。尤其是在需求不明确的时候,任何架构师都不能前瞻所有的需求。如果在项目中后期,发现需求不能满足,那么时候结果你可以想象。

第三、务实大于追新。

本人的文章,希望能给个你带来帮助:
http://mercyblitz.javaeye.com/blog/600042

最后,MVC不可能会死,只是可能解释发生了变化。模块化,分层的开发模式无论哪个组织结构都是需要的,不一定限于开发,还有政治社会一样。

在实际的应用中,除非个别的项目需要完整的MVC,就像EJB的分布一样,大多数的解决方案只是成熟模式中的一段截取实例,核心的问题是吃透业务应用,对症下药,针对具体的企业的具体业务流程实例化;关键是现在的高科技人才情愿一天到晚的DEMO,也不愿意实在的开发一个实用的信息化工具;就像老彭你的JDON,是不错,但是用量不大,量小效益就小。

2010年04月12日 10:46 "thesecondbull"的内容
个人不赞同以某某已死作为标题,毕竟mvc模式只是对项目代码在逻辑上的一个划分而已,仅为方便从代码层做管理。mvc的诞生源于对代码的放置,正如有一堆东西两个人的放置办法不同,一个人简单的堆积在一起,而另一个人做了分格然后放置。不管怎么放,放置 ...

我觉得这才是正解,mvc怎么会死呢。
只不过只用mvc搞定一切的方法会死,其实一开始人家就没说只用它搞定一切啊,一般都是些半吊子搞出来在controller里面写那么多东西的,真正明白的人谁会那么干?谁规定用了mvc就不能在业务实体里面放逻辑了,这不矛盾啊。

实际上以此理论你可以说xxx已死xxx=任何东西。
因为根本就没有什么都适合的 。

banq一个“XXX已死”,又引导一堆人思考了╮(╯▽╰)╭。在我看来,“已死”只是夸张而已,然后吸引一堆人过来讨论和发表观点。
XXX已成过去?XXX新发展?这些词多乏味啊,太过正统了。有些时候眼睛自动过滤,其实可以看看banq平时的回复,他并没有排除MVC的。所以在我看来,XXX已死只是banq夸张说法而已,是一种新闻用来吸引眼球的写法而已,回过头一想,这不就是一个新闻么?

话题扯远了~~

说DCI出现,可以说更多是由于现时的框架并不能满足需求。MVC依然存在是因为还可以满足某些需求,需求不可能一下子从一种完全变成另一种。而且一种需要很难消失的,最多是不断变少。现时的需求,更多是在互动上,比起以前一个操作一种显示(考虑方式),更多的是考虑职责分配上,所以MVC这种不是从事务,从职责出发的架构,已经“不行”了。于是某一个人提出了一种符合的架构——DCI。

其实架构师或者系统设计师,就得考虑这方面问题——项目更适合那种架构。没有完美的架构,只有适合的架构。只是市场需要让某种架构出现或成为主流而已。