一种快速开发的Java Web架构设计和实现(续)

这篇文章写得太粗糙，不想浪费大家时间（原帖删），还是看我后来的改进版吧：
http://www.iteye.com/topic/47085，
虽然它有很大的局限性，但还是值得参考，批判去看它吧。
本文的评论还是值得一读。

-----------------------------------------------------------------------
本来彻底是将本文删除的，    但还是考虑到最初想法的雏形，就还是贴出来，仅做备份。

1、 架构的抽象
     我先总整体上概括出一些抽象，然后从三层架构逐一说明：
* 计算机所做的任何工作，都是遵循这样一个过程：输入－》处理－》输出，大至应用架构，中至分层框架，小到对象方法、函数。
* 任何对象，对于其数据(属性)，都可以用Map结构的key－》value表示。如简单的JavaBean，复杂的对象，其value是另外一个Map或List。
* 任何对象，其集合都可以表示为List。

从上面的抽象来看，我所说的架构，也完全可以看成Map输入，Map或List输出，最终的输出就是html页面。
下面，我从分层的角度再逐一抽象：

1．1 持久层
我之所以先要说持久层，是因为它不依赖于其它层，这样更容易理解。
持久层是和数据库打交道的，我所指的持久层，其实不是完整的DAO模式实现，更不是ORM，只是一些Helper类， 确切的说，只要两个Helper类，一个是QueryManager，负责Retrieve，包括read和list两个只读操作，另外一个就是PersistenceManager，负责Create、Update和Delete，也就是完整的CRUD。

* 所有的数据库操作，完全可以抽象为上面的CRUD操作。譬如审批流程的通过和驳回，都是update操作。
* 对于CRUD操作，其输入是sql语句和sql查询参数，而且，sql查询参数，其实就是一个Object数组，譬如插入Database的User表，其参数是username，password，email，age，createdTime等，age是一个Integer对象，createdTime是一个Timestamp类型。
* 对于Retrieve操作，其输出是单个对象或单个对象的集合，如loadUserById和listAllUsers，而这两者可以表示为Map和List。
* 对于其它操作，可以返回void，或int，也就是update的条数，但int也可以用Map包装。

1．2 业务层（服务层）
　　业务层，也就是Service层，处理单个或复合的QueryManager＋PersistenceManager，或者处理像email通知等。譬如创建一个用户，其业务流程可能是：自动为其创建账号信息，注册其blog，发送一封激活邮件，这些全部在一个事务中。
* 对于业务层，其输入就是一个Map对象，而这Map对象主要来自于Web输入。而且，可以在这个Map里面添加其它对象，如createdTime。
* sql语句，再加上sql语句的参数，就完全可以持久化一个对象，或执行查询，而该sql参数，就来自于Map输入，这个赋值过程可能需要类型转换，但很简单。
* 对于service方法执行的最终结果，如果是数据查询，就是Map或List，对于数据操作，一般是void。而该返回值，就是Action所需要的。

1．3 表示层
     表示层，我这里主要指Web层，也就是和Web服务器打交道的那部分。
     它负责调用service层的service方法，如loadUserById，将其结果返回到前端表示层页面，service可以看成MVC的M。
* Web层的输入，如创建用户的表单form，其实，就是一个键值对，而这完全可以表示为一个Map。如果对于checkbox这类输入，譬如用户的业余爱好hobby，可以看成key=hobby，value为一个字符串数组。如果查询参数只是一个id，当然就是Map的size为1了。
* Web层调用service的输出，如果是单个对象，譬如用户的个人信息，可以看成一个Map，如果是用户列表，就是用一个个Map填充的List。
* Web层Action的处理方法，如execute()，输入路径是一个url地址，输出也是一个url地址，也就是说该execute方法，是处理Map输入，而其return是一个String类型的url， 它对应一个page页面，如userDetail.jsp。但是一定要将service调用的返回值Map或List填充上。Action就是对应MVC的C。
* 结果页面负责显示Map或List数据。这也就是MVC的V的概念。Note：WebWork和模板引擎就是这么做的。

以上就是所有的抽象，总结起来，大概就是：
* 在表示层，页面表单输入Map，在action里面处理，action里面调用service层的方法，输出Map、List或void。
* Service层的service方法输入基本为页面表单的Map，转化为sql参数，然后执行sql。输出Map或List或void。
* Persistence层的Helper方法，输入sql和sql参数，输出Map、List或void。

　　而上面的输入Map和输出Map或List都不用处理，不用Bean to Map，也不用Map to Bean，直来直往就可以了，而且添加、修改map里面信息也很容易。
　　Map to Bean这些冗余和复杂，极易出错的行为，就是Web框架如Struts的ActionForm，Hibernate的Model几乎必备的。

2、 架构的实现
     如果上面的抽象原则大家都能够认同，那么实现就不难了，而且我们也完全可以运用成熟的第三方框架，来形成我们的整体架构。不过，单独实现，形成自己的产品，也不是很难。
     贯穿在整个架构中，有两个核心概念：弱类型和容器。弱类型我是从Javascript和Ruby语言中受启发，通过Map引入到Java中来的。容器我是借鉴Lisp语言的，因为Lisp语言的原意就是：LISt Processor。
    
     持久层的实现
     持久层，主要就是将数据库的查询出来的ResultSet，转化为Map或List。由于项目时间关系，我暂时在Spring的JDBC框架上，加工出两个Helper类，处理所有sql操作，另外，事务处理直接用Spring的声明式事务。
     对于项目开发人员，都无需了解Spring，只需要了解两个Helper类的使用就ok了，事务最后由一个人加上就ok了。也就是说，省去了大部分持久层开发，这个占项目40％左右的工作量。
    
     业务层的实现
     业务层也非常简单，就是取出Web层传入的Map某些值，组成sql参数，执行sql语句就ok了，不过sql语句可能有一定难度，但去理解由Hibernate配置文件和Model生成的sql，难度小很多，而且效率也很高，即使Hibernate有Cache机制，但用好的恐怕不多。iBatis这种和Hibernate并肩的ORM框架就是手写sql的。
    
     表示层的实现
     表示层也非常简单，因为用户输入表单提交的结果Map，我只需要一个RequestParamUtils.getInput(request) 工具方法，就可以得到，而且直接将它传给service层，省去了像Struts里面的ActionForm，那冗余的字段，get、set方法。
     表示层验证：特殊的可以用validate的Java代码，一般用Javascript就ok了，而且Javascript我会形成一个类库，很easy。我们不打算用Validation框架。如果数据验证设涉及完整性，一般考虑在Database上加约束。如果用户禁用Javascript如何？请问，我们会没事把自己的电脑设置在安全模式下吗？而且IE禁用Javascript也不容易，你试试看。别告诉我我们网站的潜在用户有用IE4.0的。
     我现在是用Webwork，不过在前一个项目中，我自己实现了一个MVC的Web框架，很好用，而且不像Struts存在线程安全的问题。之所以要用Webwork，那是我担心我的framework还需要扩展。但使用Webwork，只使用其最基本的一部分，差不多就只用到其20％功能，而且是最简单的，新手一学就会，只需要理解了打印helloworld就可以胜任了。另外，我还进行了封装，提取了一个BaseAction。
     对于action处理的结果，如Map、List对象，将之填充于Request或Session对象（BaseAction会做），通过模板技术JSTL，加上JSP展现就可以了，JSTL中的tag可以处理迭代器，日期格式显示等，而JSTL的表达式语言，加上JSP，就是模板了，可以在Dreamweave下，像html那样所见即所得开发，效率超级高。
     分页处理有本架构专门提供的分页tag，项目组成员拿来用就ok了，就如同使用html的input tag一样。
    
     本架构在本人开发的上一个项目中用到部分思想，那个项目是做150多个报表查询，约500条sql语句，这些sql语句专门由一个DBA负责（报表展现的难点在sql），我负责报表展现。实际上，我花的所有的时间不到一个月（10.8—11.6），虽然有两个月期限（另外一个月基本上就是自学其它的，如Lisp、Ruby语言），总共Java代码只有2200多行，包括一个类似于WebWork的Web Framework。也就是说平均一个页面不到15行代码。而且，后来需求引起的变更基本上可以保证半小时内搞定，因为后一个月我就是每天下午5点左右花半个小时修复修复bug，然后发布新版本。
     个人觉得，一个框架或架构的判断标准，主要是“快速开发＋适应变更”，另外的附加标准是学习培训成本低。这些对于做外包项目尤为突出。asp开发部署快，学习成本低，但太难维护，特别是运行平台单一，所以逐渐被淘汰。
    
     对于Web开发，个人认为，对于产品和公司自己的项目，Java将逐渐退出其霸主地位，而会被弱类型语言，Python，特别是Ruby的Rails框架所取代，不过对于外包，这种强调团队协作，以及大型应用，Java这类强类型语言还是有其地位，因为它很容易被理解，类型就是注释，编译器检查。对于Web Service，强类型语言有其先天不足，而Web Services是未来的网络计算平台。你看Java最大的赢家IBM在干什么就知道了，它重心已经不在Java，而自觉让位于开源的JBoss。对于.net的Web开发，我觉得市场不是决定于语言有多强，而是Windows这种平台，因为我还没有发现C#比Java有多少创新，VS studio比起eclipse就不是差一个档次（不只是我这么说）。不过，在开发领域，J2EE 大概只有Servlet规范值得骄傲了，不过J2SE和J2ME还是不错。另外一种弱类型语言Javascript，随着Web2.0的兴起，Rich Client的流行，将会是一种必备语言。
     ORM，现在想来，这本身就是一种很蹩脚的东西，数据库都是关系的二维表，为什么就要转来转去的，table－》Object，Object－》table，这样很优雅？很易维护？开发更快？性能更高？我看一项都不具备。因为我们的产品，无非就是输入－》处理－》存储－》处理－》输出，为什么一定要加一个ORM层。
     领域建模，这是学习面向对象的一门必修课。但往往我们就是为了建模而建模，最后模型冗肿，实现困难，还很难维护，牵一动百，怎么去agile？领域建模，我认为主要用它来分析业务，实现未必就要ORM那套，而且，我认为最重要的是数据库E-R图，因为它是一个实实在在的东西，直接决定你的所有上层。
    
     就写到这儿了，忘了说一下，我在该架构下开发一个模块的CRUD操作5个页面，在业务清晰，数据库设计好后，开发不超过一天，工具：eclipse＋Dreamweaver。
  当然，一种架构可能只能解决一类或几类问题，但架构下的思想可能解决更多的问题，因为它是超越语言的。当然，我所陈述的思想，也只是对前人的归纳总结，灵活运用罢了。
    
    
    
    
    
    
    
    
    
    
    

评论

55 楼 cauchenlu 2016-09-08  

http://ez.web126.cn/这个不错，完全颠覆目前系统开发理论和思想，而且简单易用，功能强大。完全做到不用写代码，程序员只需关心业务需求。

54 楼 s20001 2016-08-22  

快速开发框架giiwa真心不错，简单，完全开源，http://giiwa.org

53 楼 Vcb 2015-06-10  

http://osgi.jxtech.net 是一个非常棒的OSGi企业级快速开发平台，在线演示、免费插件、完善文档应有尽有。

52 楼 belinwu 2013-09-12  

看了楼主的这篇文章，受益匪浅，尤其是对我这种刚开始步入Java Web开发的人而言，我现在的思想程度很Simple，也一直“KISS”。

51 楼 抛出异常的爱 2006-12-13  

只要重构!重构!再重构!
你的框架会越来越好用...
我以前的公司开发的框架中开发一个流程非常的快...
但是里面的代码不论早晚都是像流体一样把握不住
想加点功能....难比登天....

50 楼 pojo 2006-12-13  

希望楼主坚持独立思考精神。顶一下。楼主思考的方向是正确的。基于Map的实现，不够完备，但是作为迭代过程的初始解，也是很自然的选择。只要坚持探索，就能找出满意的解。

在我看来，许多流行的Domain Model和ORM的方案，都是丑陋不堪的。很简单的项目，硬是制造出几十，几百的XO （PO，VO， DTO， DAO， ...）。打开文件一看，大多是空的。就像一具具没有血肉，没有灵魂的骷髅。看着那样的东西，我马上就会联想到一个词-作茧自缚。所以一段时间以来，我一直想写一篇文章，介绍一个替代的选择。但是至今没有想好如何着笔，主要是形而上的部分拿不定主意。如果楼主或其他人有兴趣，我可以另开一贴，直接进人主题和数据结构。

我的方案是我前几年做项目的过程中提炼出来的。我们的项目是一个类似MS BizTalk或BEA Integration Server的项目。我们实现的是一个引擎，下游的团队用它来开发他们的项目。随着下游项目的加入，Domain Model就要修改，平均一个月改一次。所以项目的性质决定了它必须是动态的开放的。几年的实践证明了：Java也可以有"弱类型"，Java也可以是动态的，Java也可以很简洁，就看你自己怎么做。ROR的崛起，也从另一个方面证明了, 对多数项目而言， Wrapping is much better than Mapping。

49 楼 zwchen 2006-12-12  

这是我把代码贴出来后，开的一个帖子
http://zwchen.iteye.com/admin/show/38774
大家可以下载代码看看，我觉得还是很有参考意义的。

    看代码前，建议先看我原来写的两篇文章：
http://zwchen.iteye.com/admin/show/38277 （理论篇）
http://zwchen.iteye.com/admin/show/38278 （实现篇）
本文是第三篇：代码篇。欢迎大家给出公正的评价，以及待改进的地方。

48 楼 有思想的芦苇 2006-12-12  

楼主继续努力,只要善于学习钻研,前途未可限量.
BTW:有空看看Banq的文章.

47 楼 诺铁 2006-12-12  

直接jsp里面放sql岂不更简单，更适合你的团队，更符合你的逻辑？

46 楼 ASDF1982 2006-12-12  

45 楼 giscat 2006-12-12  

与LZ的思路一致，自己实现的一个超级简单的MVC框架ajf(agile java framework)
http://www.javaresearch.org/article/58413.htm
现丑了

44 楼 lane_cn 2006-12-12  

giscat 写道

mvc,用map充当model的的确是一个简捷高效的方式，
许多框架的model就是一个map或增强了的map

没有任何一个通用的框架可以提供model，model永远需要开发者根据自己的业务情况去开发。model的来源是业务需求，与技术无关。
如果一个框架提供了model，他就不是一个通用的框架了，而是一个关于某个业务领域的开发平台，例如SAP和工作流引擎。

通用的框架中不可能提供业务层，框架的任务就是为业务层去创造一个良好的条件。struts创造的条件是：业务层可以摆脱UI过程的影响；spring创造的条件是：业务层可以摆脱物理分布的影响；lz的框架创造的条件是：给了业务层一个数据库连接，并且业务层必须在sql中实现。

lz似乎认为OOP、领域模型这些东西必然和高成本、复杂、大型、>=3年工作经验、以及一大堆乱七八糟的类联系在一起。这也难怪，很多蹩脚的设计就是这样的，并且号称OOP、可扩充、灵活、高性能、易于维护，事实上一样都沾不上边。有这么多教训摆在眼前，很多人宁愿相信quick and dirty，也不相信OOP了。

43 楼 dean_liu 2006-12-12  

    真理往往掌握在小数人手中，就像十六世纪前有人说“地球是圆的”会被人笑掉大牙一样，更甚者丢掉性命。
    我觉得楼主很勇敢，在“权威”面前说了很自己想法，也许事情根本就没有所谓的“答案”。
    是先有了问题才有了技术，所谓的OO也是总结前人的经验抽象理论化出来的，OO可以解决问题，楼主的方式也同样可以解决问题（楼主没说过他的是OO），虽然这种方式看起来违背了千百万人死守的神圣教条,但它却是人类去思考去突破的一种表现，而这种表现就是人类进步的源泉。
    小弟不才，有说错的地方请纠正。还有请robin原谅我说了一些和技术无关的东西,该删就删了吧。

42 楼 zrweng 2006-12-11  

比较同意楼主，OO不是教条，框架是用来解决问题的，楼主的框架也只是MVC的一种实现而已，并没有说这是标准，简单是硬道理!

41 楼 lewisou 2006-12-11  

本人也来发表两句。看了搂主和各位高手以及菜鸟们的精彩讨论，晚辈真是受益非浅。
看得出搂主也是出于无奈，各方面的因素迫使搂主使用了这样一个架构。

引用

我所说的框架，我觉得确实会对他们有很深的误导，但现在的目标就是快速出成果啊。

我觉得要看情况的，一个开发团队如果超过5人(不包括美工)那已经是非常可怕的，交流成本过高，模块也难分，而且具搂主说一半都是新手。。。。。那确实楼主的架构或者说是方法应该是“快速出成果”的最好方法。如果5个人的团队，大家都是由点经验的，那楼主这个想法真不怎么样。

引用

你说的培训，那不是我决定的，我只是一个developer，公司大，制度就那样，我也很无奈。

确实搂主所处环境恶劣，同情。

引用

像你说的这种情况，一个公司这么多新手，我觉得还是公司管理有问题，要不为什么就留不住人呢？

显然是留不住人嘛，就这种开发团队，新手翅膀硬了不走才怪。

引用

外包，可能有时候关键得看完成的速度，其它的有时候就不重要了，再说了，对日外包有些东西也不值得去弄得那么优雅，只要不给自己找麻烦，按时交工就行了。不过就是感觉有点苦了刚去的小兵们，不过有时候也是没办法的，很多去工作的小兵都是为了去混口饭吃，没那么多理想，呵呵~

100个赞同阿。每个人的想法都不一样嘛，何必强求人家要 O O 呢。

而且搂主做的是报表系统，报表系统本来就是sql嘛，毕竟对象数据库还不成熟，Hibernate说实话做报表也不怎么方便啊。做一个sql生成器有啥不可以呢。

40 楼 zhouzulin 2006-12-11  

没有技术含量，新手上手容易，维护困难

39 楼 huangpengxiao 2006-12-11  

我们公司用的大概和你说的差不多 不过比你的设想更复杂 这样的框架似乎有个通病 强耦合 不灵活 所以应该考虑设计它的代价

38 楼 codeutil 2006-12-11  

你用的是和apache commons chain类似的链式流程处理，现在struts2里好像也用到了这个东西。
在一个chain中通过配置不同的 command来处理数据。

在业务数据涉及从不同地方的流转，用chain处理和维护都很方便灵活，不过几个麻烦的地方是
1。需要把map中存在的key和value用详细的文档进行记录描述。
2。任意一个command都可以修改map中的数据，无法对恶意代码控制。

zwchen 写道

我这个架构是处理数据流的，没有任何OO，如果你觉得很浅薄，那么请你仔细读读《面向模式的软件体系结构 卷一：模式系统》P30－P41：管道和过滤器，再过来下结论。
我这个架构的核心思想：处理Web输入数据流－》数据库，以及数据库－》Web页面展现，这两个数据管道。
我处理的是数据：不是对象！ 是不是和我们几年所学的Java纯OO背道而驰？
另外，我也和ORM背道而驰的，这和很多人的开发模式太不一样了。

37 楼 zwchen 2006-12-11  

我这个架构是处理数据流的，没有任何OO，如果你觉得很浅薄，那么请你仔细读读《面向模式的软件体系结构 卷一：模式系统》P30－P41：管道和过滤器，再过来下结论。
我这个架构的核心思想：处理Web输入数据流－》数据库，以及数据库－》Web页面展现，这两个数据管道。
我处理的是数据：不是对象！ 是不是和我们几年所学的Java纯OO背道而驰？
另外，我也和ORM背道而驰的，这和很多人的开发模式太不一样了。

36 楼 zwchen 2006-12-11  

netfishx 写道

楼主压根就还没理解OO

OO是为了什么？你能够给我一个回答吗？我这两年，考虑OO，考虑ORM太多了，发现很多很简单的解决方案，都是因为不OO，所以觉得不值得做。我现在不考虑OO，我只考虑data。现在php又似乎火了，你觉得它很OO吗？
而且，我并没有任何地方说到我这种架构有OO，本来，架构和OO关注点就不一样。而且，我在回帖里面强调过我没有用到多少Java的OO，因为我不需要。

我明天把代码贴出来，你们再评价评价吧。

我认为好的架构的惟一标准就是：快速开发＋适应变更（易维护）。