一种快速开发的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。
  当然，一种架构可能只能解决一类或几类问题，但架构下的思想可能解决更多的问题，因为它是超越语言的。当然，我所陈述的思想，也只是对前人的归纳总结，灵活运用罢了。
    
    
    
    
    
    
    
    
    
    
    

评论

35 楼 lsyong 2006-12-11  

能不能从那些人中挑2个有1年web经验的呢，然后你们也来个3人组，其他人就让他们闲着吧，反正不是你跟他们发工资。3，5个人能干的活多加7，8个只会hello world进来，很有可能就搞砸了。

34 楼 netfishx 2006-12-11  

楼主压根就还没理解OO

33 楼 clmwy 2006-12-11  

不敢苟同.我觉得楼主对OO的理解还需要加深一些.

32 楼 WorkingHard?! 2006-12-11  

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

31 楼 yfmine 2006-12-11  

赞同部分观点,像封装Spring的Helper,WW的BaseAction之类的,不过我想既然使用了这些框架,应该都会去做这些事情的,只是可以看看谁的封装更易用.
但是对于lz使用Map确实不敢苟同,不知道lz的Map里都是什么类型的数据?类型转换时是不是很不方便?有那么一点点业务逻辑时,这个处理就麻烦了,不可能全部CRUD吧.也许对于报表开发正好合适(瞎掰的)...(跑点点题:用JavaBean也不太爽,都怪getter/setter...就算没有Ruby那种attr_accessor,有个C#那种Property也行啊.本来就应该是语言层面上支持的东西,SUN那堆人真顽固...)
其实对于很多项目,使用经过简单封装的WebWork+Spring就很方便了,也应该很快速.但仅仅是对于普通项目而言,不同意lz对于ORM和领域建模的观点,当业务本身比数据库操作复杂得多时,使用你的Map就很痛苦了...而你所谈到的都是基于CRUD的操作,不知道你的快速是否也仅仅是CRUD?说ORM蹩脚太偏激了点吧,我看很多人投的新手帖...

30 楼 coolyzg 2006-12-11  

在楼主的框架中，map的维护将是恐怖的
也许你需要一个专门的文档来维护map
感觉维护的工作量很大
到了后期有种欲速则不达的感觉

29 楼 giscat 2006-12-11  

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

28 楼 ningzhisheng 2006-12-11  

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

27 楼 bluelover 2006-12-11  

而你在页面传过来的表单也可以给它弄成相应的对象,哈哈,所有的操作都是对象了,没有那多的烦恼!
至于特例吗,那就比较少了,要不就不叫特例了,可以熟知的人来搞定!

26 楼 bluelover 2006-12-11  

如果你要快速的话,干脆就不要用hibernate,不用ibatis,更不用sql语句.
你可以自己生成sql语句,在项目里面无非就那几个操作添加\修改\删除\查询\连表查询,相信正常的操作都这些,如果不正常的可以用特例在处理.你完全可以通过对象来生成这些所需要的sql语句,通过查询的结果来填充对象,所有的操作那就都是对象啦!

25 楼 zwchen 2006-12-10  

Lucas Lee 写道

Not bad!
对于很多应用，不管是"简单"，"复杂"，"小型"还是"大型"，
其实主要就是CRUD，当然还有一些常见的功能导航机制、权限控制机制。把这几个方面上的几种模式分析整理清楚了，是完全可以做一个框架来自动处理这些东西的。


我不很清楚楼主的框架，但我认为你的方向是正确的，跟我类似的。
也许你还可以更进一步，将对一个模块的CRUD用更简洁的元数据定义方式来做。
我这么说，是因为我已经这么做了，并且觉得还不错。可能比你的一个模块5个页面花一天还要快一些。
仅供参考。

谢谢你的鼓励。我现在只是希望我的解决方案能够快速解决我们团队所面临问题，而不是上面很多高手他们的问题，你说的

引用

更简洁的元数据定义方式

我再好好考虑一下，到时候再请教你。
由于业务复杂性导致的技术复杂性，大多数框架可能都有限。我只希望运用我的解决方案所遇到的技术问题，是由业务引起的，如果业务只是简单的CRUD，我认为在新手太多情况下，用不着Hibernate，因为理解那些复杂的关联确实耗费时间。别说ORM，用Java的对象思维来解决问题也需要时间。
现在做项目，很多时候不是完全按自己的意志，因为有一个所谓的团队啊，你得考虑别人的现实情况。

24 楼 LucasLee 2006-12-10  

Not bad!
对于很多应用，不管是"简单"，"复杂"，"小型"还是"大型"，
其实主要就是CRUD，当然还有一些常见的功能导航机制、权限控制机制。把这几个方面上的几种模式分析整理清楚了，是完全可以做一个框架来自动处理这些东西的。


我不很清楚楼主的框架，但我认为你的方向是正确的，跟我类似的。
也许你还可以更进一步，将对一个模块的CRUD用更简洁的元数据定义方式来做。
我这么说，是因为我已经这么做了，并且觉得还不错。可能比你的一个模块5个页面花一天还要快一些。
仅供参考。

23 楼 zwchen 2006-12-10  

downpour 写道

我觉得楼主说话越来越偏离主题了，你的题目是很“技术”的，但是越到后来，你越强调你团队中其他成员的问题。

你如果想说你的这种框架和设计能够让新手快速上手，我认为这会对他们有很深的误导，让他们觉得原来web应用就是这么开发的。我现在周围就碰到不少同事，还在把HttpServletRequest传到DAO层，我敢说这就是一开始做web应用时习惯没有养好，对什么是对的，什么是错的没有一个基本的认识。

如果你要继续纠缠一个框架是否能让一个连helloword都写不出来的新手快速上手的话，你为什么不从根源上解决这个问题？他们是怎么进入公司的？既然已经进入了公司，还是以培训为主，我想任何一个新手，只要认真学习，1到2个月的时间足以让他们了解一个好的web应用的开发流程和开发方法。

是的，讨论已经偏离主题了，但是，我那个帖子本身，也没有多少技术可言，一开始我就这么说。
也许我的帖子的标题很有问题。
我所说的框架，我觉得确实会对他们有很深的误导，但现在的目标就是快速出成果啊。
你说的培训，那不是我决定的，我只是一个developer，公司大，制度就那样，我也很无奈。我也很希望给他们培训啊，但资源不是我能够调遣的。项目组只有到最后编码的时候，项目经理才附带说说培训的事情，但培训往往就只有两小时，三个框架（WSH）。也许在他心中，只要是搞软件的，一学就会吧。

22 楼 zwchen 2006-12-10  

taowen 写道

最终结果是这帮啥都不会的“程序员”就能写程序了？太神奇了……崇拜。你分配给他们干了什么工作了？不会操作实例变量，倒会操作map……

taowen兄，不知道你是否了解大连的对日外包。虽然我们部门是做国内项目的。我现在所希望的是那些新手能够完成他们的工作，完成基本的CRUD操作，我们还谈不上什么业务。
不知道你是否在想，还要这样的人来干活？为什么不培训，或者找熟练的。对不起，部门就这么多资源（人员、时间）调遣，你得面对这残酷的现实，我也很为难啊！
我现在发这篇文章的目的，就是希望有更多的人发表看法，我一开始就知道很多人觉得我的帖子很幼稚，但只要能够帮我在这种状况下完成预期的目标行了。
技术这东西，我觉得可以解决问题就行了。往往20％的技术就可以解决80％的问题，我现在就希望这样。代码的可维护性，我也在考虑，但似乎讽刺意味的是，我所见到的几个项目，几乎都没有维护性，用了webwork＋spring＋Hibernate，但一人一套，因为每个人只需要用任何方式把自己的模块完成就行了，这是惟一的标准，是不是很恶心？Note:这些项目我基本只是旁观者，我自己有其它活。

另外，我觉得可维护性的一个很重要的原则，就是职责分离，这也许是我上面提到的框架的惟一优点，姑且说是优点吧。

21 楼 downpour 2006-12-10  

我觉得楼主说话越来越偏离主题了，你的题目是很“技术”的，但是越到后来，你越强调你团队中其他成员的问题。

你如果想说你的这种框架和设计能够让新手快速上手，我认为这会对他们有很深的误导，让他们觉得原来web应用就是这么开发的。我现在周围就碰到不少同事，还在把HttpServletRequest传到DAO层，我敢说这就是一开始做web应用时习惯没有养好，对什么是对的，什么是错的没有一个基本的认识。

如果你要继续纠缠一个框架是否能让一个连helloword都写不出来的新手快速上手的话，你为什么不从根源上解决这个问题？他们是怎么进入公司的？既然已经进入了公司，还是以培训为主，我想任何一个新手，只要认真学习，1到2个月的时间足以让他们了解一个好的web应用的开发流程和开发方法。

20 楼 taowen 2006-12-10  

一起无奈。面朝大海春暖花开。

19 楼 zwchen 2006-12-10  

taowen 写道

至少不能通过技术来解决。技术只能解决技术上的问题。用技术来解决技术之外的问题，我看很困难。管理问题，团队问题，就该用管理手段，沟通手段去解决，别拿技术下手。而且我也没看出“绕开”Java的强静态类型带来的好处。少写两行代码吗？RoR开了这么一个比较代码行数的风气真是不好。程序的价值体现在维护上。代码少，也许能够说明好写。但是不一定就代表好维护。当然，俺没说RoR不好维护。。。（是不一定哦）

你说的我很受启发，我也应该好好思考管理的问题。
另外，也许Javaeye是一个高端论坛，所接触的大多数人，所在的公司牛人都比较多，或自己本身就是，所做的项目也有高手把关，但我所在项目，往往是项目时间耗得差不多了，留半个月一个月（20％）给设计、开发和测试，而且项目组都是新手为主，项目pm最关心的是他所看到的，。
也许，我说的解决方案很无奈。

18 楼 taowen 2006-12-10  

最终结果是这帮啥都不会的“程序员”就能写程序了？太神奇了……崇拜。你分配给他们干了什么工作了？不会操作实例变量，倒会操作map……

17 楼 zwchen 2006-12-10  

另外，我知道我上面所说的基本算不上什么架构，那所谓的抽象你们一看就懂，但你们在下结论之前，请了解一下我所遇到的项目的现实：项目组很多人对Java语言的实例变量、静态变量可能就是不是很清楚，我对他们没有任何偏见，只是这是一个现实，我的目标是怎么去帮助他们实现他们的目标－－项目leader给他们每个人安排的模块。
我们不是精英团队，不是robbin开发javaeye论坛那超级三人组合。

16 楼 taowen 2006-12-10  

至少不能通过技术来解决。技术只能解决技术上的问题。用技术来解决技术之外的问题，我看很困难。管理问题，团队问题，就该用管理手段，沟通手段去解决，别拿技术下手。而且我也没看出“绕开”Java的强静态类型带来的好处。少写两行代码吗？RoR开了这么一个比较代码行数的风气真是不好。程序的价值体现在维护上。代码少，也许能够说明好写。但是不一定就代表好维护。当然，俺没说RoR不好维护。。。（是不一定哦）