一个Java框架引发的思考：语言、框架、范式转换和软件生产力

前几天，iteye上的pojo同学，发来了他四年前写的一个框架demo(原帖在这里1 2)，那一年，我也写过一个App框架。
我们的出发点都差不多：利用Java语言提供的弱类型、动态性，来解决Java语言本身的死板、臃肿。
另外，在数据建模上，我们也差不多。其实，所有的原子级数据结构，都可以简化为Map、List、Tree这三种基本类型，而且Tree还可以进一步原子化为Map+List。

先说说pojo同学这个eXtream框架吧。
它建模于数据管道这个概念，可以理解为Linux的管道模型，如grep命令。管道模型可以分为两块：
1、数据流的输入源、输出端。如Linux grep命令可以将数据查询、处理结果输出到文件、控制台等
2、数据流在管道里的处理过程(filter模式) 。如more命令的“|”参数

eXtream框架解决了2，对于1，只是用PipeUtil工具类解决，如HttpServletRequest/Response等输入输出，我认为这是完全可以进一步抽象化的，就如同java.io数据包里的类设计。

eXtream这个框架技术实现细节我就不提了，我从更实际的角度来谈一下eXtream以及编程语言和生产力的关系。

语言、框架及软件生产力
像我和pojo同学，都是对Java语言这些特性提出质疑，才开发自己的框架。现在想起来，只是“不识庐山真面目，只缘身在此山中”。如果我们真的想Java足够的动态、灵活，为什么要选择它呢，Ruby是一门更优秀的语言啊，它的ActiveRecord足够强大了。

我当初之所以会开发这一框架，还是站在个人生产力+软件开发阶段角度。从项目管理和商业角度，决定一种语言和框架是否适合，有两点：
1、团队生产力
2、软件全生命周期(可维护性)

对于1，一种语言对团队的要求是，必须规范、一致，绝不允许太个性化(容易出现Bug黑洞)。Java语言提供的静态编译和强类型，以及eclipse等工具的即时检查，让几十人的开发团队可以一起协作，有序、持续的开发。
附带说一下，如果ActionScript(flash)不是基于强类型、静态编译型，Flex就很难在企业应用Rich Client上大有作为。ActionScript和Java我感觉没有本质上区别。
当然了，如果你们是精悍小团队，希望软件尽快上线，那些灵活的框架，如RoR用用也无妨。
之所以很多人觉得Java笨，我认为是不知道怎么剪裁，就像RUP，不会剪裁基本上就没法应用，Rational公司还专门针对敏捷开发，出了RUP剪裁版。

对于2，还是因为Java语言的强类型和简单性(代码即文档)，让软件代码整洁、易读，再加上前期的规范约束，“易改”(可维护性)成为了可能。
大家知道，软件开发行业，developer在一家公司平均呆两年，如果他不离职，在一家公司呆了两年后，也基本上会换岗。而一个企业项目的生命期一般有3-10年，甚至更长，维护者和开发者肯定不是同一批人。再说，开发人员(打江山)和维护人员(守江山)完全是两类个性的人，比如维护人员不太可能是有野心、有激情、喜欢挑战的人。

语言、框架的范式转换
每一种框架都有其设计理念，比如struts和webwork本质上没啥区别，都是基于Request/Response模式，所以学会了struts很容易上手webwork。但JSF就完全不一样，基于event的模式让人很难思维转换，这也是JSF不太容易上手的原因，因为它不太符合开发人员的“直觉”：Web开发不就是http请求/响应吗？
如果你做过Flex或是Swing开发，你会发现Event-Listener模式是其核心，一旦了解了Event-Driven原理，开发就很简单了。
还有，像Web Flow这类思想的框架，把一系列页面都串联成flow也让人费解，因为从Web角度考虑，页面只是在一个请求/响应生命期，没有工作流的概念。

再说说eXtream，它将Web请求/响应，业务处理等特定逻辑，都抽象为数据管道，一个人要进行这种范式转换，有个适应期。这就像为什么用惯了Windows的人，非常不适应Mac系统，反之亦然。
再说，进行业务处理时，总要想到in、out、一次次对数据进行filter这种技术逻辑，是不是和我们的出发点：专注于业务相悖？
像苹果的iPhone(iOS)，就让我们忘记“文件系统”这个概念，专注于你的资源。

也许，你这种框架，适合特定的应用场合，充当基础设施，如数据转换、传输。

每一种技术、业务场景，都有其最适合的概念建模，如果这种建模和该业务场景匹配，则我们很容易理解。一直用命令式语言，如C/Java朋友，试试Lisp这种函数语言，你就知道自己有多么的不适应，因为你的思维已经定势了。
大家有没有想过：sql是一种和Java并列的描述型语言？
JavaScript是基于prototype这个概念。不了解prototype，JavaScript永远都谈不上精通。
建议顺着这篇文章一直读下去：http://en.wikipedia.org/wiki/Programming_paradigm

当然了，如果见过大量不同设计思想的语言、框架，你就会上升到更抽象、本质的高度。做J2EE开发的朋友，如果立志做架构师，一定要看看.net是如何处理类似问题的。

再说eXtream的技术实现。从开发的角度，如果通过框架再重新定义一套规则，如sql查询，这会加大学习成本，影响新人的上手速度。Hibernate用到HQL，就已经够折腾了(sql确实没法解决解决对象查询)。

最后总结一下。
如果你是架构师，你应该了解eXtream这类框架的设计及实现；
如果你是项目经理，你应该坚决地放弃这种框架的引入，因为项目经理永远考虑的是成本、收益、进度和风险。再说，从纯技术角度去提高软件生产力，微乎其微(人月神话大家都认同吧？)。

附件那个demo，是没法运行的(缺很多jar包)，不过eXtream的应用示例，大体可以理解该框架的设计思想。
那个demo是用户注册、管理，业务很好理解。

类似ActiveRecord这样的东西，在很久以前的开发工具，诸如delphi，PB，VB中比比皆是，它们在面向数据或SmartUI的开发方法中举足轻重，但是它有一个缺点，那就是用一个通用的数据集掩盖了业务的模型或者或业务的语义，不知道随着应用的复杂的不断提升，这样的开发工具是否还有生命力。不用分析业务的语义和模型，直接快速地得到用户界面固然比较好，但是一旦应用规模扩大，维护者很难知道为什么要那样写SQL语句，而且必须通过字段的字符串引用才能得到数据，这与目前流行的领域模型驱动有很大的不同。当代的软件开发趋势是期望应用通过若干可以自由插拔的组件构成，组件模型用来反映业务本质。JavaEE6中的CDI 强调的是类型安全的依赖注入，就是增强这种组件中之间的组合能力，或许我的看法片面，不知道楼主对此有何看法？

顺便说一下，ActionScript语言既可以支持强类型的静态的类型检查，也可以支持动态的类型，并可以通过FlashBuilder进行编译器检查，我感觉和楼主说的恰恰相反，仅就开发效率，产品的效果而言，FLex做企业应用开发再合适不过了。Flex与Java的组合，是企业应用开发一条比较合适的路径。

楼主所说的框架我确实一无所知，但是若果我们把所有的业务操作都归结为CRUD，又对我们开发有什么好处呢？

看君一篇文，还要多读几本书啊！功力不够啊！加油啊！

楼主的文章我一向是能看得懂，但是要让自己操作起来，却很有难度。望楼主指教一二。

Martin Fowler的企业应用架构模式已经写的很好了。
POJO说的那种，虽然公司在用，但我不用。说说让我印象深刻的缺点，开发效率很低，随着系统功能增加，显而易见，调试起来不方便，很容易有BUG。非常不适合企业应用开发。

楼上说的没错，十几年来，基于dataset开发的软件系统一直都有那样问题，不仅如此，系统之间的集成（数据和应用集成）一直很差。所谓面向对象模型的不稳定和易碎是单纯从技术角度考虑问题而不考虑业务的程序员得出来的不全面的结论，很多程序员梦想开发一套什么动态的系统来解决这些问题，最终把编程技术高度抽象为对数据集的增删改查。这是沿着一条错误的道路勇猛之前，如果那条路可以走得通，Delphi，VB等早就解决了那些问题。这是与我所看到的国际的主流信息化建设思想完全背道而驰的错误思路。在物联网，尤其是智能电网建设的大背景下，欧美一直将重点放在开发稳定，通用的基于面向对象描述的业务模型，他们为此开发了大量的标准，覆盖了人、财、物、客户、组织、费率、工作排程、资产、价格、设备、智能楼宇、智能表计等很多方面。

如何能够更好地利用面向对象来解决问题，我建议读一读四人帮的设计模式，这是最基本的，之后，根据需要看看这些网站提供的面向对象的业务模型：
http://www.opengroup.org(开放群组官方网站) 包含很多通用业务模型。
http://cimug.ucaiug.org（智能电网—CIM用户群组官方网站）CIM模型，电力领域，并引用了其他领域通用模型。
http://www.iec.ch/ （IEC官方网站） CIM模型，电力领域，并引用了其他领域通用模型。
http://www.mimosa.org/（机械信息管理开放系统联盟组织官方网站） 资产、设备维护模型。
http://www.cim-ple.com/ （CIM模型研究网站） CIM模型，电力领域，并引用了其他领域通用模型。
http://www.oagi.org/dnn2/(开放应用群组官网站) OASIS模型，人财物领域。
http://www.opengeospatial.org/（开放地理信息联盟官方网站） 地理信息模型。

以上观点仅从个人经历出发，可能偏面，请大家批判。

现在javaeye真的是很少有这样的好文章了，我想问一下，怎么投精华啊？

很明显感觉功力不够

我之所以废弃原来那种框架设计方法(我没有在文中链接到到该文章)，也是意识到复杂业务系统，必须有清晰的、静态的、稳定的领域模型，比如社保、货运等领域模型，10年可能都不会有多少变化。而且，从技术实现角度，企业应用偏向于写操作，弱类型的数据操作业务一复杂就很容易失控，因为没有约束检查机制。
所以，eXtream那种数据管道模式的偏技术实现的框架，我觉得也不太适合企业应用开发，尤其是大团队协作式开发。

当然了，对于偏向互联网网站这种以读为主的业务场景，弱类型还是有优势，比如Spring JDBC + Spring MVC + EL这一套。