有了OO、分层、DI、AOP、TDD和Refector,DDD不再是空谈

一晃眼搞了7、8年的企业应用管理和研究,各种技术、思想翻来覆去折腾了很久,最近总算是有点持拨云见目的感觉了,于是放出点大标题和各位论论道。

主要观点其实在一年半前,已经在jdon首发的文章“坚持发扬EJB、Spring的光辉思想,将组件化进行到底!”(可参 http://www.jdon.com/jivejdon/thread/31834.html)进行过论述。当时虽然观点比较激烈,然实际上笔者领悟得不够深刻,故有后面一年多的RoR和PHP之实践。随着时间的推移,与各相关方(上级领导、企业领导、用户、开发商主管、设计人员、开发人员、维护人员等等)的更多观点接触,让我逐渐深入领悟了Java和Spring所蕴含的开发哲学和思想,于是又有此文。
(上文刚刚收到blog,由于是老文,不再发布了,仅作为整理收录)

如果说,每种编程语言和技术都有自己的目标和归宿和话,那么简单来说,JavaEE和后来的Spring是为企业应用而生的。他们诞生的基本目标,正是为了解决困扰企业应用多年的各种复杂问题。故而他们能够达到现在的领导地位,并将一直延续下去。

世间各种事业,都应该是“统一规划,分步实施”。放到信息工程来说,就是“自顶向下设计,自底向上实现”。道理谁都明白,可现实当中执行下来,总是要走样。问题就在于,这二者该如何结合?于是实际项目中,企业用户、分析师、设计师、程序员、维护人员总是不欢而散,最后往往各行其事,一盘散乱。上层的总是抱怨下层在“乱搞”,而下层则嘲笑上层只会“空谈”。结果往往是早已扔进档案袋的系统方案和图表,一堆各种公司、各种程序的“系统”,蒙头蒙脑瞎忙的维护人员。

那为什么结合不了?因为大家没有“共同语言”。开初UML跳出来了,分析师讲得头头是道,程序员看得心烦意乱,用户更是云山雾水。于是连MF都有点烦了,干脆推起了RoR。这乍东西一看太理想了。几乎是分析员可以直接实现程序,而程序员也可以直接分析了。可惜世间难有完美的事物,RoR这种过于“ 霸道”的东西也许还是有问题的。前有foxpro,后有VB、PB,也许是笔者总是心有余悸,对这种过于“完美”的东西还是先放一放吧。

那是不是说,大家真的不可能有“共同语言”?笔者以为,有,但要折衷(又闻到了实用中庸主义的味道了吧)。如题,OO、DI、AOP、TDD和Refector正是当前的解决之道。

OO是根本,可以作为基本的“共同语言”。图表不必要像UML那么复杂,否则最后除了分析师谁都不会看。只需要简单建上模型,标上属性和接口功能,最多连几根线说明相互关系,这样大家都懂(也就是说,这个类是个什么东西,有什么属性,要实现些什么功能)。这种东西既可做系统说明书,也可以给开发人员,甚至生成Doc做维护文档。
大家要说这不是“空谈”吗?要的就是空谈(就好比不识字的老百姓也会谈治国问题),就是只谈“有什么”和“做什么”,这样才能有共识。但这种“空谈”其实最难最费时,因为要“共识”。有了共识之后就可以下一步了。

下一步是实现。这个阶段,分层、DI、AOP就可以大展本领了。Spring流行那会,大家是言必DI和AOP。可惜风头一过,现在RoR和 Seam时尚年代,很多人大概忘了七七八八。其实笔者现在看来,分层、DI和AOP是继OO之后最重要的思想,它们的核心在于“接口和实现分离”。这样一来,就可以把“做什么”和“怎么做”分家,这才是它们的伟大之处。大家天天把“高内聚、低耦合”挂在嘴边,各搞一套,乱七八糟。J2EE太复杂,大家觉得用不上。好不容易Rod推行了用得上的标准方法,大家本可以有“共同语言”了。可惜人之天生的惰性又把我们推回到“一体化”的泥潭,一代代程序员和系统就这么不了了之了。

OO还是要坚持,它是当前信息世界和现实世界实现映射的最好方法。DI和AOP也是要坚持,只有这样才能屏蔽掉具体实现技术疯狂变化的信息世界。坚持OO,我们才能不受数据存储方式变化的困扰;坚持分层、ID、AOP,我们才能明确地分工合作,摆脱系统规模和事务要求变化所带来的烦恼。

最后还有TDD和Refactor,业务在变,系统在变,我们的技术也在变。一定要能测试和重构,要能很好地测试和重构,否则系统必被变化所毁。要想能够很好地测试和重构,如果你的系统没有OO、分层、DI、AOP,大家是否真可以充满底气地回答“能”。在这一个问题上,Java是最令我放心的伙伴,而Spring更总是带来惊喜。

DDD(领域驱动设计)是一个好的设想,而如今像Spring这类的标准化框架则可以把这个设想变为现实。在这个设想里,管理人员、分析师和用户定义模型功能要求,架构师根据要求选择技术方案,不同的程序员(有做dao的、做service的、做view的)根据接口要求实现代码,通过测试后提交。而因为有支持分层、DI、AOP的框架存在(比如说Spring),布署人员就可以简单地把他们组装在一起。
面对不断的需求变化,分析师仍然只需增加/变动模型和功能接口,测试人员和编程人员按作相应变化即可。
总体设计、分步实施、按需定制、分工合作、无缝组装,这种工业标准化的软件开发方式才是企业应用的答案。而OO、分层、ID、AOP、TDD和Refactor是真正支撑这个开发方式的支柱。以这样的方式,DDD会真正成为现实。


信息发达国家的软件业其实很大程度上已经实践了这种开发方式(想想那些大规模的外包吧)。这些年国内搞Java的,张嘴闭口便是SSH。可惜很多人搞了一些年后,还是“不识庐山真面目”,成天抱怨“好烦”。在这样浮燥的产业环境下,国内大多数企业应用的质量是低劣的。
即使你天天在写Java、天天在用Spring,如果不能够“知其所以然”,那么你的SSH注定是偷工减料的豆腐渣。所以在此劝诸位从事企业应用的同道,好好静下心来,认真思考一下你的应用所面对的各种问题,再好好思考一下OO、DI、AOP、TDD和Refator给你带来的福音。

愿大家的系统质量都能更上一层楼,这样才可变恶性竞争为良性合作,让我国的信息系统发挥更大更好的作用。

LZ说的很好。很有深度,国内许多企业只注重眼前利益,不愿意过分的产品拖的研发时间太长。哎,而且还定死技术选择。

我只能说,顶.有思考力的人,如果都这样想就好了.

>>DDD(领域驱动设计)是一个好的设想,而如今像Spring这类的标准化框架则可以把这个设想变为现实。
这句话,晚辈不是很理解,还请前辈们点拨,我觉得spring对DDD的作用也不是很大(但是不能否认spring给企业级开发带来的革命性的新思想),我们现在最多也就是将系统的service和一些repository类交给spring ioc容器装配,让IOC 容器来帮我们管理它们的生命周期,并且让spring管理事务等,但是对于我们的业务核心,实体,值对象等都需要自己管理,比如通过聚合,工厂,仓库来管理,而spring是不能管理的,所以有点不解,请各位道友指点迷津。

基本认同前辈的观点,但有一些观点,我不大认同,下面我对此谈一下我的几点思考。


On 2008年12月31日 11:30, “lgx522” wrote:

>下一步是实现。这个阶段,分层、DI、AOP就可以大展本领了。Spring流行那会,大家是言必DI和AOP。可惜风头一过,现在RoR和 Seam时尚年代,很多人大概忘了七七八八。其实笔者现在看来,分层、DI和AOP是继OO之后最重要的思想,它们的核心在于“接口和实现分离”。这样一来,就可以把“做什么”和“怎么做”分家,这才是它们的伟大之处。大家天天把“高内聚、低耦合 ”挂在嘴边,各搞一套,乱七八糟。J2EE太复杂,大家觉得用不上。好不容易Rod推行了用得上的标准方法,大家本可以有“共同语言”了。可惜人之天生的惰性又把我们推回到“一体化”的泥潭,一代代程序员和系统就这么不了了之了。
>...
>即使你天天在写Java、天天在用Spring,如果不能够“知其所以然”,那么你的SSH注定是偷工减料的豆腐渣。

您说“又把我们推回到‘一体化’的泥潭”,是反对现在的RoR、seam等full stack framework吗?那您是鼓励大家花大把大把的气力去自己整合S.S.H.,以及其他可能需用到的各种各样的技术吗?有能力把这个事做好,固然再好不过,问题是什么人都能做的好吗?即便做好了,重用性能有多少?要做好这件事需要深厚功力的,如banq能做出一个jdon framework出来,提升到了框架的高度;您“搞了7、8年的企业应用管理和研究”,或许也能做出一套自己的最佳实践出来。但是如果没有您们这样的功力,即便他“知S.S.H.之所以然”,也无法把这三者整合好,也无法进而做好自己的project,只能是偷工减料的豆腐渣。

掌握了基础设施原理,学会优秀的设计思想、设计模式、设计方法,到最终把这一切付诸实践,获得最佳实现/实践,这“想”与“做”之间的距离,绝对要比你想象的要大的多,不是什么人都能轻易跨得过去的。

暂时跨不过去怎么吧?这时不能什么都不干啊,该干嘛还得干嘛啊,这时候就可以去用“full stack framework”。一个优秀的full stack framework,其关键意义之一就在于“无缝整合”四字,整合各种各样你需要用到的优秀技术,给你一个优质的基础设施、基础平台(避免自己整合搞出偷工减料的豆腐渣工程来),让你直接可以在此之上构建上层建筑。但又不会把你绑定在某个或某几个特定的技术上,用什么、不用什么,完全由你自己选择,同时又不用担心整合的问题,有能力的话,还可以方便的加入自己的扩展。所以,full stack framework绝不是“泥潭”!也不是让你丢弃“OO、分层、DI、AOP、TDD和Refector,DDD”,而只是帮你做了一些核心工作,让你不用那么辛苦,不用什么都要去从零开始或从一个很低的起点开始做起。

继承别人的成果不可耻,直接使用别人的成果也不可耻,在别人已经达到的高度上继续努力,才能走的更高、更远,发展才能更迅速。重复别人已经做出成果的事情,那才是无意义的很。那些什么东西都希望自己从原理出发,自己设计、自己实现出来的人,是出于一种什么心理、心态?你想向世人证明你多么聪明,能发明出这么好的东西来?

不要只继承前人的总结出的思想、原理(OO、分层、DI、AOP、TDD和Refector,DDD),前人优秀的具体实现成果也要继承。 等到了你真正能够跨过“想”与“做”之间的距离时,你可以做出自己的基础设施,再用自己的基础设施搭建出自己的 full stack framework来,把这个留给后来人,作为后人继续发展的平台,如此传承、进步不息... 这才真正叫做“自己的贡献”。


[该贴被dearshor于2009-01-01 17:12修改过]

以上两位还是对此进行过思考的,就起讨论一下吧。

这个事情从大方向来说是“分”与“合”的矛盾,也就是大家熟知的“天下分久必合,合久必分”。软件业几十年大体上也就是各种分分合合的好戏。

J2EE的核心思想在于“分”,如果大家没有经历过VB、Delphi、PB那个辉煌的年代,是不大明白为何要“分”的。当时上述RAD的那种惊人生产力,比现在走上神坛的RoR还要高得多,于是各种“信息管理系统”铺天盖地。可惜时间一长,无数的“信息孤岛”把企业信息扯得支离破碎,维护人员更是疲于奔命,各种“系统”自然也就很快地花开花落。

Spring是为了解决当时EJB“繁琐”的问题,但Spring时至今日仍然坚持“分”(也就是组件化),甚至比J2EE走得更远(J2EE必竟还是要服务于各厂商的)。“接口与实现分离”是Spring的核心思想,大家要用心把握。真正领悟到这一点,文章里的各种设想才会真正落到实处。领悟不到的话,就必然走回RAD的老路,无非是换个Web平台。这个问题banq以前说得很清楚,砍掉几个层,自然就简单了。这与现实世界的规律是一致的,小作坊的各种事情都是“合”,这样高效快捷;大组织的事情则是“分”,这样才能分工合作。经过几十年的实践,软件世界亦是这样的规律。

OO、DI、AOP、TDD、Refactor,Spring是至今仍是领头羊。所谓“整合S.S.H”是不贴切的,事实上Spring是主板,大家无非选择插上Struts(也可以是JSF、WebWork、Tapestry等等)和Hibernate(或ibatis、JDBC、JDO等等)。这种可接插是很重要的,这样才能随需变化,才会有分工合作。
中国的软件业要上台阶,首先就是要清除小作坊式“唯我独尊”的愚蠢观念,学会分工合作。这个问题上,以Spring为代表的可接插式开源框架为大家提供了很好的范本。

On 2009年01月04日 09:16, lgx522 wrote:
>所谓“整合S.S.H”是不贴切的,事实上Spring是主板,大家无非选择插上Struts(也可以是JSF、WebWork、Tapestry等等)和Hibernate(或ibatis、JDBC、JDO等等)。这种可接插是很重要的,这样才能随需变化,才会有分工合作。

可能“整合”二字在这里是我用词不当吧,我就是这个意思。这里关键就是“选择”和“插上”。首先,可以是Struts,也可以是JSF、WebWork、Tapestry,如何选?选哪个?这个不是人人脑子里都能清楚的。其次,如何“插”到spring上去? spring并不是out-of-the-box的,而是原生态的,什么都要你去再加工,就是说不是直接“插”上去就得了,这样是“有缝”的,你还要自己写代码来“粘合”这些“插”上去的东西,来达到“无缝”,这个更不是人人做的来的事。(见上文讨论)

从您的字里行间看,您觉得full stack framework就是“合”,就是想恢复“VB、Delphi、PB那个辉煌的年代”吗?
我认为,full stack framework就是解决了上述的两个问题。如今的技术、框架何其多?不可能每一个都去了解、去研究,然后选出符合我要求的,并想法把他们“插”到spring上去的。哪来那么多时间和精力。但更没时间、精力,也不是什么人都有能力自己从DDD出发做一个自己的框架(如jdon)出来,所以还得用现有的,顶多是将现有的组合一下。
这方面我深有体会,刚出校门开始工作的时候,面对那么多学校里没接触过的技术、框架,要从中选出几个来组合使用,在根本不知道以哪个为“主板”的情况下,还要组合的好。事隔多年,现在回忆起来那简直是噩梦,完全不得法。所以后来当我看到full stack framework(如jboss seam)的时候,唏嘘不已。如果当时就有full stack framework,那我该多轻松。

您说“如果大家没有经历过VB、Delphi、PB那个辉煌的年代,是不大明白为何要“分”的”。我的确没经历过那样一个时代,我出道时,那个时代已经过去,但VB、Delphi、PB这些我在学校时都学过,所以也了解一些VB、Delphi、PB里的“合”。但我要说的是,现在的full stack framework里的“合”绝不同于VB、Delphi、PB里的“合”,此“合”非彼“合”。

Java一向是开放标准的,所以一个合格的Java (EE) full stack framework绝不会将developer禁锢其中,什么都要按照它选定的技术、模式、框架,不得越雷池一步,完全不会。拿jboss seam为例,高度的out-of-the-box(开箱即用),却又高度的optional、高度的customization,developer完全可以按自己的需要来选择自己希望使用的技术、框架来“插”到seam上来实现自己的业务,并且不会因为对可选的技术、框架等不熟悉而不知如何选择,如何结合使用,这一切seam都会帮你决定。seam中筛选、推荐了很多各色各样优秀的现成的东西,并为之提供了完美的插入点、粘合点,使得你不需要太多了解你选择的技术、框架(如JSF,ejb,flex,jbpm,drools,cache,portlet,etc.),就能将这些东西应用自如(不要以为我信口开河,我有切身体会,我学seam的时候,对seam涉及到的各种技术、框架都不了解,甚至对jsf与ejb3也一样),这样的“合”,何乐不为?何乐不受?说到“可接插式开源框架”,seam首当其冲的要列入其中。
[该贴被dearshor于2009-01-09 16:29修改过]

大家讨论很好,我也从中启发不少灵感,我个人总结如下:

我大概在2005年很早就提出可彻底配置的组件化,主要目的还是应付快速变化的需求,当所有组件都可以自由拆开Ioc/DI,运行时也可自由指定顺序AOP,那么我们就能够更快地跟随变化,甚至无需重新编译整个项目,只要带一个组件到现场,XML配置改写一下,就能上线运行,注意,我这里提到了XML配置,如果你完全使用现在潮流Annotation就达不到这个目的。

而毫无疑问Spring/Seam都在向Annotation方向迈步,他们打出的旗帜就是简化!

我个人觉得他们简化的方向有点偏,当框架组件变成可彻底配置以后,就应该以业务为核心开始收了。

如果单纯从收这个动作来看,我个人认为Seam要比Spring做得更好,Seam完全是从平台构件方向进行整合。

但是令我失望的是:他们收的整合的方向没有顾及到业务,也就是Domain Model。注意:Model是一个对象,它的敌人就是数据库,这两个架构SSH和Seam都包含Hibernate等ORM框架,可惜因为Hibernate自己本身因为花费太多照顾对象和数据库的映射,也就是变成专职的调解员,身陷对象和数据库的纷争之中,身陷庐山中,不识Domain Model真面目,变成有以为利的地步了。

说的通俗一点就是:Hibernate等ORM变得复杂而重了,这种重量开始牵制它服务的主人Domain Model了,以至于Domain Model使用Hibernate开始冬眠睡觉时,投鼠忌器了。

所以,话说回来,我们到底是以Spring这样一个非业务所谓技术而技术的纯平台组件为核心主板,还是以Domain Model这个业务核心为判断技术的唯一标准?这又是一个方向问题,又是一个路线问题。

只有这个基础问题搞清楚,才能真正达到"无以为用"的地步,也就是说:可能只有抛弃造车这些专业技术平台概念(“无”的含义),才能用好框架。

道德经解道之二:有之以为利 无之以为用:
http://www.jdon.com/jivejdon/thread/35372.html
[该贴被banq于2009-01-10 09:56修改过]
[该贴被banq于2009-01-10 10:11修改过]

banq前辈总结得很在理。

关于配置是用xml还是用annotation,我的观点是:一个都不能少!该用xml的地方就要用xml(比如部署描述符),该用annotation的地方就要用annotation(比如OR-Mapping,entity level validation)。

xml的优点是:纯文本形式的,修改以后无需重新编译;能够表达复杂的层次、结构、逻辑等。缺点是:缺乏合理的默认值;校验难,缺乏编译器级别的校验;文档缺乏(多数dtd、xsd中是没有写文档的),查阅文档不方便(分散在dtd、xsd中的doc很难阅读,缺乏ide支持;而annotation有javadoc,IDE对javadoc的支持很完美)。

annotation的优点是:有合理的默认值,使得配置代码的量大大减少;易于校验,有编译器的支持;文档丰富,阅读方便,ide支持好。缺点是:无法表达复杂的层次、结构、逻辑等;修改以后需重新编译。

将这2者结合起来,就比较完美了。值得庆幸的是,目前大多数情况下,xml配置都可以作为alternative来override annotation配置,也就是说,这2者已经可以接近完美的结合起来了。我至今认为,用JPA用annotation来做OR-Mapping,用orm.xml来提供override机制,是一种很大的进步。
seam也提供了这样的机制,其唯一(one way principle)的xml配置文件components.xml(除了jsf、ejb的部署描述符,jbpm流程定义文件等)里配置的component,可以override built-in component(默认情况下,built-in component的install precedence比用户定义的component的install precedence要低),通过定义install precedence,也可以达到让components.xml里配置的component override 用户(通过annotation)定义的component。
但我在spring2.5中,却没能看到这样的override机制。

至于“可彻底配置的组件化”,我不确定“组件化”和“模块化”能否划上等号,姑且认为这两者只是粒度上的不同吧。
谈到“模块化”,我就会想起OSGi,至少觉得OSGi这个东西,在架构上、部署上都是很符合banq所说的“应付快速变化的需求”,“只要带一个组件到现场”,甚至连配置都不用修改,把旧的bundle卸载,然后直接把这个新的bundle部署上去(如果你愿意,甚至可以不用卸载旧的,让新旧2个版本共存),其它bundle自动发现服务,自动更新自身状态,我觉得这简直太酷了~~

关于IOC/DI,随着未来seam3的推出,seam背后的web beans将会成为IOC/DI的全新规范。
而OSGi,在springsource的推动下,相信在Java EE领域也会大放异彩,我很期待~~
[该贴被dearshor于2009-01-11 19:44修改过]

to dearshor:
seam玩过几天,设计上很棒。本打算深入,可惜性能实在不敢恭维,也就暂停了。楼上玩得久,可以谈谈这方面经验。

Spring可接插性的优势,更主要地是体现在团队合作上。比如说有的团队喜欢Hibernate、有的则是Ibatis或干脆JDBC;又如表示层既可选择Web,也可利用Remoting选择RIA或RCP,大家擅长的技术不同,而应用的场景也有异。这种情况下,可以在不同的时间、不同的模块、不同的场景下自由选择。这对于合作开发是很有意义的,对于长远维护则更有意义。
初学者可能会被Spring的这些“选择”搞得心烦意乱,其实Spring也可以是“一栈式”的。Spring jdbc+Spring MVC就是非常好的选择。

最后再补充一下,Spring在功能足够丰富,设计开发规范性,适度易用的前提下,保持了相当高的性能。况且群众基础非常好。大家可以衡量一下各种各样的framework,就企业应用来说,Spring当前无疑是最合适的选择。

to lgx522 前辈:
您说“seam的性能实在不敢恭维”,不知道是否您经过了大量的、精准的benchmark test后得出的结论?如果仅仅凭感觉,是很不准确的。和谁做的比较?是同等条件、同等usecase下比较出来的结果吗?

seam不像spring那样,没有自己重新开发一个stack出来,而是用了现有的Java EE stack。你说的性能问题,如果确实存在,那也是JSF的性能问题,或ejb的性能问题(或其他seam整合的东西的性能问题),而seam只会让它们在seam中比以前跑的更好,绝不会是更差。

很多人抱怨seam的conversation性能很有问题,我认为是他们还不会用conversation。试问,你的app里很多地方有必要使用 long-running conversation吗?未必吧。transient conversation就如同request一样,这和spring里的情形没什么区别了,还觉得有性能问题?

ok,退一步讲,就算有性能问题,牺牲了我一些纵向扩展的能力,但我可以无限横向扩展啊,我搞cluster可以吧?只要你愿意,搞多少台app server组cluster都可以。

至于您说的“团队合作”上的优势,spring有,seam同样有,没什么大区别(我在学seam之前也用过spring相当长的时间。spring我也还是看好的,特别是它吧OSGi真正引入Java EE领域这一做法,我很欣慰)

好了,这个讨论已经跑题了,我们居然争论了这么多seam和spring的区别与各自特点,哈哈。该打住了。

to dearshor:
首先要肯定你的钻研和独立思考精神,保持这样的劲头必有所成。现在国内大多数程序员是人云亦云,只会被动式地接任务编程,是很难有进展的。

所谓seam,就是EJB3+JSF,而当前seam的性能的确是低的。Web应用有一个大的分界点,那就是“有状态”和“无状态”。传统的Web都是“无状态”的,而过去的session bean和现在的seam都大胆地引入了“状态”。设计上的确是很棒,但性能的问题还是会摆在眼前。至于慢多少,随便找个工具如ab、jmeter测一下,就会有认识了。这一点上,包括本人曾实践过一阵子的Grails,完成后是转换成Spring+Hibernate,想像上应该和纯正的SH没有太大区别,可惜事实上性能差距很大,正应了“without EJB”中Rod对动态语言转换编译的前瞻性论断。

cluster这种问题,其实是是很难考证的,因为cluster本身要同步数据就有不小的开销。jboss cluster玩得熟的,可以做一下,看看同样的机器配置,多少台装载seam的cluster才可以达到一台装载SH的性能。而中间层cluster最关键之处,还是要解决DB的单点瓶颈问题。这一点上,Hibernate的second-lever cache同样很棒,用上jboss cache之类的东西也是可以做cluster的。
最后用Rod Johnson的观点总结一下近期本人暂不考虑seam的原因吧,观点大概是要首先保证高效的单机应用(Spring同样是可以伸缩和扩展的),再考虑群集的问题。这几年的事实证明了Spring的正确。而本人由于最近在搞Spring remoting+Applet,很大程度上可以是“无状态”,就更不需要seam这类的东西了。

另外扯一下题外话,banq在理论上是相当激进的,而jdon framework性能却相当地不错,可见banq的务实和老练。往这个方向发展的同道,大可以学习参照一下,不要总不把国人的东西当回事。Discuz!都红遍全中国,大家没有必要继续漠视国产优秀的Java OpenSource。

选择哪个工具是典型的www问题,大部分人都对what和how有过深入的了解,但是where就要更深入的分析才行。给几百人用的和给几百万人用的当然不一样。
seam推荐是full,但也可以les,spring默认是les,也不是不能ful。没有where,这些东西是没办法比较的。

On 2009年01月24日 09:45, "lgx522" wrote:
>不要总不把国人的东西当回事。Discuz!都红遍全中国,大家没有必要继续漠视国产优秀的Java OpenSource。

前辈说的很好,我一直热衷于开源软件,十分希望OpenSource也能真正成为“中国创造”。对国产开源软件,我一向是支持的; 对于jdon framework这样的优秀产品,我一向是肯定的。

但目前我主要聚焦于“应用”上,应用现有的东西来做ending user application,故可能更多的关注的是解决实际问题、提供整体解决方案等层面。现有的哪个东西能解决我的实际问题,能提供完整的解决方案,不用我为选择而犯愁、为组合而烦恼,我就选择谁,至于它是国产的还是洋人的,我基本上无所谓。
而对于基础设施、中间件平台、开发框架等的设计上的研究,目前暂不打算深入。以后也许会考虑。

开源软件在国内的发展还有很长的路要走,至少目前还很不成熟(无论是开源社区、developer、用户/客户、市场等)。不说别的,很多国人都不知道如何向开源社区提交自己的贡献!其实“贡献”分很多种,比如提交一个bug report,那就算是贡献啊;很多国人都不知道使用开源社区的mailing list,甚至不知道mailing list为何物!

我目前自问也还没能力像banq那样写一个jdon出来支持国产开源软件的发展,我能做的仅仅是试用、比较各类开源产品,并试图找出best practice,分享给国人,也算我为国产开源软件的发展出了一份力吧。

PS:目前我在Google Code托管了一个keepleaping project,就致力于做上述事情。
http://code.google.com/p/keepleaping/

问题的根本 不在于用什么技术 而在于领域本身 所以ddd开篇讲得好,使用‘通用语言’构建模型才是好的解决方法。否则就算你精通这技术,精通那技术,到头来连问题本身的尾巴都没摸到,其不是南辕北辙。这也就解释了为什么人家写出那么恶心的代码,用户还是欢天喜地的原因。之所以用lz所说的那些,目的就是为了可维护,可扩展,可伸缩。