一种快速开发的Java Web架构设计和实现（代码篇）

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

评论

26 楼 mubenchi 2007-02-28  

zwchen HISOFT有你这样的高手啊 早知道我不换公司拉，到你手下干活 那学问可是大大的学习！

25 楼 zwchen 2007-02-13  

请参考我后续的改进，可以回答
jiming 和蓝色之心 的建议：
[url] http://zwchen.iteye.com/admin/show/47085[/url]

24 楼 蓝色之心 2007-02-06  

大体看了一下，框架是在WSH的基础上进行了一些封装，已达到用户更快的使用WSH的效果，
楼主的精神值得肯定，建议楼主能不能写一份文档，用户要做哪些工作，让用户体验你的“快速开发”呢？

23 楼 jiming 2007-02-06  

为什么不看看 ibatis

22 楼 zwchen 2006-12-16  

经过近一周的思考，我发现我所陈述的东西，根本不是什么架构，也不是框架，因为架构和框架的关注点和我陈述的观点关系并不大。也许，只是对某类问题的一种解决方案罢了，或许会比较适合在需求阶段做prototype。希望不要误导大家。

不过，我现在正在考虑怎么去实现一种持久化解决方案，也许不OO，没有ORM（在研究Hibernate实现），但可以比较方便解决某类问题。

下面是我引用RUP文档里面关于architecture的定义和描述，在RUP里面是4＋1视图：
Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives。

在我以前的项目经历来看，架构特别关注以下几点：
可扩展性：譬如eclipse的OSGI，JBoss和weblogic的JMX微内核。
性能：如ebay架构的非cluster，无状态架构，google的服务器集群。
可伸缩性：系统对负载突增的承载能力（负载/响应时间）
安全性

而框架，用google的define:framework 搜索结果：
In software development, a Framework is a defined support structure in which another software project can be organized and developed. Typically, a framework may include support programs, code libraries and a scripting language amongst other software to help develop and glue together the different components of your project.

我觉得，框架特别看重重用、易扩展、灵活。

21 楼 lane_cn 2006-12-15  

Lucas Lee 写道

为了实现而实现，不好么？为了领域模型而领域模型，好么？
世事无绝对。所谓权衡。

软件的用处是什么？实现业务领域的自动化。领域问题的复杂度是软件必然无法回避的。控制问题可以省略，直接拿UI调用业务代码。DAO可以省略，业务代码可以直接调用JDBC。但是领域问题永远无法省略。

不实现领域模型可能吗？表面上可以，很多软件做出来一个领域概念也没有，一个业务对象也不写，照样运行的很正确。但是业务逻辑已经扩散到UI、控制器、Service、DAO这些东西里面去了，实际的工作一点也没逃掉，该写的业务代码其实一行也没有少写。

20 楼 LucasLee 2006-12-14  

zwchen 写道

不过，这样做项目，感觉只是为了实现而实现，放弃了领域建模那些用Java优势的地方，不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。

为了实现而实现，不好么？为了领域模型而领域模型，好么？
世事无绝对。所谓权衡。

19 楼 zwchen 2006-12-14  

引用

我的建议还是一样，"元数据"化。
你看你的代码，都已经整理得比较清楚了，我估计你再写几个模块，代码模式、结构基本都一样。(我也经过这么一段时间，开始觉得很规整，有点软件工程的意思，但后来觉得枯燥，总是在重复。)那么究竟哪些地方不同呢？无非就是表名、字段、字段类型等等这些“元数据”是不同的，那么将这些元数据抽取出来，单独定义，那么剩下的不就是完全一样的东西么？那么不就能做成一个统一的唯一的程序么？
就是说，一个支撑、解释程序，加一些元数据，可以构成一套完整的系统。

我这里还没有提及灵活性、扩展性的部分，但至少就简单的数据维护部分，上述思路是适用的。

是啊，如果要真的再进一步，就是你说的这个路线了，谢谢你的提醒。
不过，这样做项目，感觉只是为了实现而实现，放弃了领域建模那些用Java优势的地方，不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。

现在倒是想按Lucas Lee 的思路做做看，做做尝试，要是做得比较成功，过段时间就把代码公布出来，再让大家评评。

18 楼 LucasLee 2006-12-14  

zwchen 写道

Lucas Lee 写道

我看了超过5分钟，没看出来是什么逻辑。
解释一下，比如新加入一个简单的表，如客户类型，只有两三个字段的，需要配置哪些东西，写那些代码？

如果你新加一个简单表，需要的简单流程：
1、在db里面创建该表
2、在sql1.properties里面定义一条sql语句，如client_type_insert=insert into.....，并且在db的sql编辑器下测试通过
3、写ClientTypeService类的CRUD操作，继承于BaseService，请对照UserService。对于一般的操作调用，之用调用pm（PersistenceManager）和qm（QueryManager）进行操作就ok了，不过其它的，如存储过程，需要扩充那两个类，因为现在它们还不完整。
4、写ClientTypeService的单元测试代码，如ClientTypeServiceTypeTest。
5、写ClientTypeAction类，继承于BaseAction，参考UserAction
6、用dreamweaver写jsp页面，不过建议，95％的情况只需要将jsp当作模块语言，如freemaker。

整个过程熟练后，写代码很快，不知道大家是否以前有asp和php的开发经历？有就更好了。因为只有对比才理解深刻。

本应用的缺点：
1、当操作的table字段太多时候，在service层里给参数赋值确实有些烦琐，虽然很简单，hibernate为我们自动做了，但对于新手，配置那些1:1,n:1,n:n的关联，lazy loading，以及cascade和inverse很花时间，当然高手就另当别论了。
2、从jsp页面字段、到db操作字段的对照关系，这些都必须清楚，也就是说数据的key是层间约束的。其实用asp和php时这些都是默认规则。

另外，系统肯定有一些不完善的地方，因为那个demo应用的整个开发，包括基础类，我只花了两天左右的时间。

我的建议还是一样，"元数据"化。
你看你的代码，都已经整理得比较清楚了，我估计你再写几个模块，代码模式、结构基本都一样。(我也经过这么一段时间，开始觉得很规整，有点软件工程的意思，但后来觉得枯燥，总是在重复。)那么究竟哪些地方不同呢？无非就是表名、字段、字段类型等等这些“元数据”是不同的，那么将这些元数据抽取出来，单独定义，那么剩下的不就是完全一样的东西么？那么不就能做成一个统一的唯一的程序么？
就是说，一个支撑、解释程序，加一些元数据，可以构成一套完整的系统。

我这里还没有提及灵活性、扩展性的部分，但至少就简单的数据维护部分，上述思路是适用的。

17 楼 zwchen 2006-12-13  

jkit 写道

zwchen 写道

Lucas Lee 写道

我看了超过5分钟，没看出来是什么逻辑。
解释一下，比如新加入一个简单的表，如客户类型，只有两三个字段的，需要配置哪些东西，写那些代码？

如果你新加一个简单表，需要的简单流程：
1、在db里面创建该表
2、在sql1.properties里面定义一条sql语句，如client_type_insert=insert into.....，并且在db的sql编辑器下测试通过
3、写ClientTypeService类的CRUD操作，继承于BaseService，请对照UserService。对于一般的操作调用，之用调用pm（PersistenceManager）和qm（QueryManager）进行操作就ok了，不过其它的，如存储过程，需要扩充那两个类，因为现在它们还不完整。
4、写ClientTypeService的单元测试代码，如ClientTypeServiceTypeTest。
5、写ClientTypeAction类，继承于BaseAction，参考UserAction
6、用dreamweaver写jsp页面，不过建议，95％的情况只需要将jsp当作模块语言，如freemaker。

你接下来应该考虑怎么实现下面的东西，否则不能算快速开发。

引用

砍掉2，5
简化3, (4自然也跟着简化了)

是啊，不过确实应该考虑怎么简化3，不过2我觉得不用砍掉，因为经常遇到客户最后要求将某某字段排序的需求，所以还是在properties文件里面稍微灵活点，而且也方便测试优化sql：直接将sql编辑器里面的代码copy过来修改一下。
5应该没法砍掉吧，不过你的想法很值得我思考。
现在忽然想想，做这样的简单应用也确实没有多大挑战，当初有这种想法，主要是想怎么让项目组的新手可以快速开发，少让他们加点班，因为项目经理只管看到实际效果，其它就什么也不过问了，譬如培训什么的。

做外包，我觉得一般技术含量都偏低，而且做应用软件不像产品，它很多时候并不需要接口，抽象类可能会用些，而在系统软件开发，这是一个必须，所以开发过程中我们会感觉比较别扭，就像论坛有人问有了Service，可不可以不要DAO，其实，这类简单 应用不要也罢。如果我们的项目现在用Hibernate，我们根本不会考虑用iBatis，如果我们花了100W在Oracle上，我们以后根本不太可能考虑用DB2，它和产品开发差距太大了。
  不过，做外包，有时还是长见识，譬如我一直在做的一个项目，软件开发费用在1500W，很多子系统。不过某些方面可能不专，因为都是用别人的产品来开发嘛。

16 楼 jkit 2006-12-13  

zwchen 写道

Lucas Lee 写道

我看了超过5分钟，没看出来是什么逻辑。
解释一下，比如新加入一个简单的表，如客户类型，只有两三个字段的，需要配置哪些东西，写那些代码？

如果你新加一个简单表，需要的简单流程：
1、在db里面创建该表
2、在sql1.properties里面定义一条sql语句，如client_type_insert=insert into.....，并且在db的sql编辑器下测试通过
3、写ClientTypeService类的CRUD操作，继承于BaseService，请对照UserService。对于一般的操作调用，之用调用pm（PersistenceManager）和qm（QueryManager）进行操作就ok了，不过其它的，如存储过程，需要扩充那两个类，因为现在它们还不完整。
4、写ClientTypeService的单元测试代码，如ClientTypeServiceTypeTest。
5、写ClientTypeAction类，继承于BaseAction，参考UserAction
6、用dreamweaver写jsp页面，不过建议，95％的情况只需要将jsp当作模块语言，如freemaker。

你接下来应该考虑怎么实现下面的东西，否则不能算快速开发。

引用

砍掉2，5
简化3, (4自然也跟着简化了)

15 楼 zwchen 2006-12-13  

这是我以前写的一篇文章，现在放在Javaeye上，是关于Web开发的总结：http://www.iteye.com/topic/38882，我把它放在了新手区，因为我觉得确实很简单，不知道大家看法如何？

14 楼 zwchen 2006-12-13  

zzname 写道

zwchen 写道

4、这个可以在Web框架里面解决，这不是我的关注点，而且，我认为基本的Web框架，特别是基于request的，如Struts和webwork，都无法简单解决这个问题，而且解决很复杂，一年前，这个问题我就觉得是web框架的无奈，因为我的action里面这些代码占据了很大一部分。

5、关于VO： 你说的100个字段的table，确实用jdbc直接做很费劲，如果真的有这样的需求，就不用考虑我这个了。不过对于Map这种东西，你看Servlet规范里面的HttpServletRequest，HttpSession，和ServletContext，其实最重要的功能，我认为就是提供了一个Map，特别是HttpSession，简直就是一个Map实例，tomcat的实现中大概确实这样吧，大概是有一个map实例对象处理setAttribute的存值，

如果你认为“这个可以在Web框架里面解决，这不是我的关注点”，那就你的demo代码就只剩下三个特点：
1，抛弃使用VO保存对象，改为使用Map
2，将SQL语句从逻辑代码中分离出来，通过调用资源文件获取
3，调用spring实现操作数据库的基本功能
也就是不包含web层的设计与实现。你的题目：一种快速开发的Java Web架构设计和实现，就应该去掉web架构设计和实现。
如果字段多了，用JDBC直接做很费劲，那这种设计就是通过简化功能来实现开发的快速。

我想现在的结果和你刚开始的想法肯定偏离了方向。我以前的毕业论文和你的这个东西很相似。现在回头看，是别人用了很多时间走出一条路，我也同样花了很多时间重新走出另一条路，最后发现自己走的路和别人走的都到同一点了，但还没有别人的好。（开会了。。最后一句没有说好）

是你说的这么回事，web层的东西我是通过webwork去做的，不过不要model，也许是对JavaBean有些烦了吧（只有get set方法那个）。另外，最主要的就是项目团队的问题，大多数人不会web开发，真不知道怎么让别人快速上手，其实webwork，Spring，Hiberante这些东西挺简单的，至少很多核心源码我都读过。但别人不会用，随便用，最后搞乱套了，烦啊，不过我不是leader，也许和我关系不大。但加班，你得跟着啊。

13 楼 zzname 2006-12-13  

zwchen 写道

4、这个可以在Web框架里面解决，这不是我的关注点，而且，我认为基本的Web框架，特别是基于request的，如Struts和webwork，都无法简单解决这个问题，而且解决很复杂，一年前，这个问题我就觉得是web框架的无奈，因为我的action里面这些代码占据了很大一部分。

5、关于VO： 你说的100个字段的table，确实用jdbc直接做很费劲，如果真的有这样的需求，就不用考虑我这个了。不过对于Map这种东西，你看Servlet规范里面的HttpServletRequest，HttpSession，和ServletContext，其实最重要的功能，我认为就是提供了一个Map，特别是HttpSession，简直就是一个Map实例，tomcat的实现中大概确实这样吧，大概是有一个map实例对象处理setAttribute的存值，

如果你认为“这个可以在Web框架里面解决，这不是我的关注点”，那就你的demo代码就只剩下三个特点：
1，抛弃使用VO保存对象，改为使用Map
2，将SQL语句从逻辑代码中分离出来，通过调用资源文件获取
3，调用spring实现操作数据库的基本功能
也就是不包含web层的设计与实现。你的题目：一种快速开发的Java Web架构设计和实现，就应该去掉web架构设计和实现。
如果字段多了，用JDBC直接做很费劲，那这种设计就是通过简化功能来实现开发的快速。

我想现在的结果和你刚开始的想法肯定偏离了方向。我以前的毕业论文和你的这个东西很相似。现在回头看，是别人用了很多时间走出一条路，我也同样花了很多时间重新走出另一条路，最后发现自己走的路和别人走的都到同一点了，但还没有别人的好。（开会了。。最后一句没有说好）

12 楼 zwchen 2006-12-13  

lane_cn 写道

lz的代码我看了一下，象这样的框架，也许每一个初次搭建项目框架的人都做过一个。我以前也做过这样的东西：前台一个jsp，中间搞一个action，调用一个helper，后面是ado，然后是database。很多人都做过大同小异的东西，好像是该用的东西都用上了，各部分的分工都很明确，然后大家把画面分一分开始干活吧。很简单，很容易就出来看得见的东西，项目经理心里觉得很安全，进度都在控制中。

但是到了最后，这简单的东西会急剧复杂化，业务代码里面充满了500行的if，十几层的for循环，业务流程都直接挂在数据库上，关联性很复杂。然后就是项目经理不断的强调编程规约，抽出一个个的函数，但是复杂无法得到解决。

现在lz处于这样一个阶段：已经有一定的编程经验，语言方面已经不是问题了。但是对于软件的构架还是有一些糊涂的，搞不清楚层次、对象这些东西究竟是怎样安排的，搞不清楚为什么使用了先进的技术没有使系统变简单，而是变复杂了。于是不相信这些技术，还是相信自己的直觉，靠无微不至的管理措施弥补设计方法的欠缺。

等lz的经验再能丰富一点，就能摆脱现在的状态，不再为了控制器、service、action、dao这些东西伤脑筋，可以把精力更多的放到业务领域上。lz目前的思路还是从技术角度看问题的。比如lz代码中为java程序划分了多个package，这个划分其实是不合理的，完全是从技术的角度划分的，实际上java的package体现的应该是业务领域。

也许你觉得目前接触的项目太简单，不值得使用那么复杂的手段。实际上，你现在干的项目已经有一定的复杂度了。你可以说报表的数据很简单，不值得建立领域模型，直接用sql就可以了，这个我很同意，没有必要任何地方都非oo不可。但是至少报表本身的展示、传阅、保存、修改，是有一定复杂程度的，即使你的系统中只有一个对象——报表——都是好的，开发和维护过程中，你都可以得到很多方便。

推荐你看一本书：领域驱动设计，蓝色的封面。

谢谢你的建议。《DDD》这本书我一年前下载过，放在机器里，不过没怎么看，看来我是需要好好读读。不过对现在的MDA自动生成代码，还是保留看法。
去年，我参加过一个物流系统的开发，是一套产品，现在是3.0，700w行代码（一套300W美金），里面有复杂的领域建模，DB表有300多个，那个系统，，有空就研究研究，如果考虑用我这个，肯定死翘翘。
也许是现在做的有些项目，太过简单了吧，谈不上架构，还得多请教请教前辈，所以我这个帖子，也是想得到你们的指点，因为javaeye高手多嘛。

11 楼 zwchen 2006-12-13  

together 写道

从数据库开始也不是不可以。但如何把数据库之间的复杂关系完整的映射到系统中去，就是一件很困难的事情了。到时候你的这种方法就不是简单，而是复杂。

所以到最后，你可能会发现，你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。

从习惯于从数据库开始，到习惯于从java po开始，是非常漫长的一个过程。但这是必须要走的一段路。

是的，你的观点我很认同。因为我们大半年前做业务分析时用Rose来建模账号＋用户＋角色＋组织结构＋权限时，发现必须有领域模型，才易于分析，而且hibernate和领域建模相处很和谐（贫血的model）。

不过，技术这种东西，用一种用多了，你会发现什么你都会想到它怎么解决，但有时候，它可能不是最佳解决方案。我发现，做项目，特别是大项目，做多了，你会发现代码是很小的一块，很多东西是非代码的，而是某个方面的思路：如cluster，权限，事件模型，异步模型，SSO，容器生命周期，这些都是我一年来处理的。

10 楼 lane_cn 2006-12-13  

lz的代码我看了一下，象这样的框架，也许每一个初次搭建项目框架的人都做过一个。我以前也做过这样的东西：前台一个jsp，中间搞一个action，调用一个helper，后面是ado，然后是database。很多人都做过大同小异的东西，好像是该用的东西都用上了，各部分的分工都很明确，然后大家把画面分一分开始干活吧。很简单，很容易就出来看得见的东西，项目经理心里觉得很安全，进度都在控制中。

但是到了最后，这简单的东西会急剧复杂化，业务代码里面充满了500行的if，十几层的for循环，业务流程都直接挂在数据库上，关联性很复杂。然后就是项目经理不断的强调编程规约，抽出一个个的函数，但是复杂无法得到解决。

现在lz处于这样一个阶段：已经有一定的编程经验，语言方面已经不是问题了。但是对于软件的构架还是有一些糊涂的，搞不清楚层次、对象这些东西究竟是怎样安排的，搞不清楚为什么使用了先进的技术没有使系统变简单，而是变复杂了。于是不相信这些技术，还是相信自己的直觉，靠无微不至的管理措施弥补设计方法的欠缺。

等lz的经验再能丰富一点，就能摆脱现在的状态，不再为了控制器、service、action、dao这些东西伤脑筋，可以把精力更多的放到业务领域上。lz目前的思路还是从技术角度看问题的。比如lz代码中为java程序划分了多个package，这个划分其实是不合理的，完全是从技术的角度划分的，实际上java的package体现的应该是业务领域。

也许你觉得目前接触的项目太简单，不值得使用那么复杂的手段。实际上，你现在干的项目已经有一定的复杂度了。你可以说报表的数据很简单，不值得建立领域模型，直接用sql就可以了，这个我很同意，没有必要任何地方都非oo不可。但是至少报表本身的展示、传阅、保存、修改，是有一定复杂程度的，即使你的系统中只有一个对象——报表——都是好的，开发和维护过程中，你都可以得到很多方便。

推荐你看一本书：领域驱动设计，蓝色的封面。

9 楼 zwchen 2006-12-13  

zzname 写道

认真看了一些代码。要实现当前功能代码还是比较干净。但是如果要在这个基础上实现更负责的功能，就不好处理了，或者处理好，但代码结构很别扭。在实际应用中，都会有以下几点功能：
1，事务处理。在对多表操作时中没有看到事务处理的代码。我没有认真看过spring，如果要加上事务，怎么办。
2，条件查询，排序。就是在查询出来的列表中，添加条件查询。按照这种结构思路，如果要增加条件查询，只能有两种选择：
   第一，在sql1.properties增加固定条件，在页面获得查询值，把这些查询参数作为参数设置。这种做法只能固定一些字典查询，不能实现动态条件查询。
  第二，组织条件sql,比如：where field1=** and field2 = **。编写这个过程的代码是很复杂很费时间的。
3，排序。和第二差不多。
4，页面转跳。这是最麻烦的事情。前面一些问题可以在你代码结构的基础上找技巧可以解决，但这个问题在你代码中没有看到任何解决方案。比如你根据条件(field1=v1 and field2 = v2)获得一个列表，点击其中一个记录的修改按钮，然后在修改页面点击保存按钮，然后回到列表页面，怎样保证那些条件的设置值还保存？在实际系统中，到处是这样的转跳，不复杂，但很麻烦。如果在实现过程中，没有快速开发的解决方案，算不上是快速开发架构。顺便说一下，AJAX的最初出现的原因就是为了解决这种问题。如果不使用AJAX解决,又不解决这个问题，实际是用2年前的思路在开发

另外在代码中，我第一眼发现的是使用Map来代替了VO来保存对象。虽然Map在存取上的时间都达到常量，但总觉得不雅观。即使性能上不考虑，在开发中，获取一个对象的时候，肯定经常要copy字段放入get()中。如果是100多个字段表，开发过程中，其中一个字段对不上，要找出来，够受的。用Map的其它弊端，看看其它人怎么说。

对于你提出的问题，我发表点看法：
1、事务处理：由于我的持久层工具类是基于Spring的，它自动管理数据库连接池，事务可以在Spring配置文件里面declare，这个很简单，不过我的demo代码中并没有配置，以前我处理JTA时候，还用到过JTOM，那个可以嵌入式跑，Spring也提供了简单的集成（JotmFactoryBean），我当时比较典型地应用是在osworkflow集成上。

2、3：这两个看来就没有hibernate灵活了，确实在我这个应用里面处理起来都很机械，不过效率应该更好控制

4、这个可以在Web框架里面解决，这不是我的关注点，而且，我认为基本的Web框架，特别是基于request的，如Struts和webwork，都无法简单解决这个问题，而且解决很复杂，一年前，这个问题我就觉得是web框架的无奈，因为我的action里面这些代码占据了很大一部分。

5、关于VO： 你说的100个字段的table，确实用jdbc直接做很费劲，如果真的有这样的需求，就不用考虑我这个了。不过对于Map这种东西，你看Servlet规范里面的HttpServletRequest，HttpSession，和ServletContext，其实最重要的功能，我认为就是提供了一个Map，特别是HttpSession，简直就是一个Map实例，tomcat的实现中大概确实这样吧，大概是有一个map实例对象处理setAttribute的存值，

我觉得什么应用框架，都有其实用范围，就像很多人看不起EJB，但是，我们仔细看看EJB规范，EJB的目标有三个关键字：分布式、事务、组件模型，这是官方对EJB描述时说的第一句话。而不是JavaBean，OO。当然这些在EJB3.0很有改观。

大家可以把他当作一种解决问题的方式，就行了，特别是一般的非复杂业务系统，中小型应用，譬如电子政务网站。

8 楼 together 2006-12-13  

从数据库开始也不是不可以。但如何把数据库之间的复杂关系完整的映射到系统中去，就是一件很困难的事情了。到时候你的这种方法就不是简单，而是复杂。

所以到最后，你可能会发现，你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。

从习惯于从数据库开始，到习惯于从java po开始，是非常漫长的一个过程。但这是必须要走的一段路。

7 楼 有思想的芦苇 2006-12-13  

想知道楼主在那家公司.