可爱的javaee：非框架架构漫谈
概述
你可以说可爱的php，可爱的ror，可爱的python，甚至可爱的.net，但是javaee？他太复杂了。相比前三种技术，javaee的技术体系更全面、更规整也更复杂，他的复杂性也让很多厂商望而止步，宁可选择简单甚至简陋的php，这充分说明快速开发是这个时代最迫切的需求。
javaee的servlet、javabean、jdbc规范给了我们组件和容器的唯一标准，而更高级的支持，jsf、jdo规范却没能给予我们唯一的框架级标准，他们被认可的程度远低于相同领域的开源框架。尽管开源社区给了我们最丰富的选择，但是相比.net、php、ror的全栈式服务，javaee开发者必须DIY。DIY不但需要时间而且需要冒险，这种发烧友做的事情是企业所不愿意做的。一段时间以来，公司javaee方向的招聘几乎清一色的要求struts、spring、hibernate这几种主流框架的能力就是一种证明。
javaee的开发往往避免不了配置之旅，尽管很多框架都有自动生成工具，但是，面对一个中型项目，仍然容易造成混乱。配置使你无论在开发、测试、集成还是维护的时都要配置代码两头看。配置给了框架一个注入服务的切入点，但是对人并无优雅可言。ror给了我们启发，尽管企业开发是复杂的，但是大多数的需求都是通用的，事实证明，ror把这部分通用性用约定的方式抽象得很好。其实javaee并不缺乏约定，因为他本身就是建立于一系列规范的基础之上，而规范就是约定。所以，javaee实际上有机会成为相对简洁的开发技术，只不过由于种种原因，这种规范并未出现。
在众多的javaee开发框架中，struts+spring+hibernate有着黄金组合的美誉，用的人多，会的人多，就算是没出校门的学生，也知道学会ssh的重要性。但是学会和学懂是两码事，对于一个中型项目，ssh就成了一柄双刃剑，需要由高水平的设计师引路，才能披荆斩棘。spring+hibernate给了设计者广阔的空间，而设计需要因项目的前进而演进，如果你的项目进度紧张，人手不足，设计质量就难以保障，给系统带来隐患。
“任何优秀的语言，都可以帮助开发者写出优秀的代码，但不能阻止开发者写出糟糕的代码”。在这一点上，无论是javaee，.net，ror，php都不会例外。而开发框架就像是“一间有很多屋梁的房子”，“框架的强大之处不是他能让你做什么，而是他不能让你做什么”，其实如同语言一样，框架虽然可以给予开发一定程度的规范指导，但是这种指导仍然是有限的，这真应了那句老话：事在人为。
本文试图探讨如何简化javaee开发中不必要的复杂，并给出的是一个不使用任何框架的架构模型，让我们看看仅仅通过用编码约定，结构设计和使用方式的组合能不能满足项目开发的主要需求—短期培训，降低隐患和快速开发。
问题的源头应用软件开发是复杂的，但其基本模型至为简单，请求－处理－响应。对应于软件的层次结构就是：请求－Cortrol（C）；处理－Model（M）；响应－View（V）。在早期的javaee应用中，servlet负责C，javabean和jdbc在M，jsp是V。这些就是javaee的基础设施，他们职责划分的方式被称为JSP Model2，已经可以满足web开发的基本需要，javaee的开发始终都围绕着这几项主要技术，框架也不例外。以下的内容，将从这些技术的应用与不足说起，然后介绍主流框架的解决方案，之后再介绍我们不用框架的处理方式。
(C)选择控制器?
可以看出，只需将实体类名引入标签，我们就可以获得自动拼装的Worker对象。对于复杂对象或复合对象，由于request里同样有我们需要的所有请求参数，所以你可以在自动创建的javabean基础上修改部分属性，以符合业务需要。
代码还展示了基于“method”的用法，这只是一个字符串，用来告诉 jsp要用哪个方法来处理请求，这类似于ror控制器内部定义的方法以及struts的DispatchAction但比他更灵活，变通的解决了jsp的请求不能直接面向方法的不足。
在调用服务处理请求之后，worker_input_st.jsp将处理结果out.print回客户端，这句代码的意思是新建一个JSON对象，将处理结果添加进去，然后输出这个对象，方便客户端js脚本解析。JSON对象可以增加多个处理结果，只要他们的key不同就可以。在实际应用中，往往返回处理消息，或者html视图的字符串。最后别忘了return;否则程序仍然会向下进行。
如果你的项目需要国际化，我们可以使用fmt标签，而对于反馈消息的国际化，我们也许就需要建立一个全局MessageSource对象了，这个问题在webappdemo中没有涉及，因为笔者认为这不是普遍需求。
对于异常处理，其实jsp已经提供了简单的机制，我们可以在web.xml中配置：
<%@ include file=”../common/import_page.def”%>
这里使用了相对路径，增加这个文件是为了方便的引用其他css和js库文件。使用这种方式可以避免在部署的阶段因合并js或进行css、js库文件的版本变更而带来的麻烦。
再来看看java src的目录结构：
webappdeom
??? common
??? worker
datasource.xml
log4j.properties
除了根目录，与WebRoot下的结构是一致的。两个文件：datasource.xml是数据源配置文件，也是笔者demo中使用的API所需要的，log4j.properties是log4j的属性文件。另外，系统默认使用hsql数据库，如果要正常启动，需要改动web.xml中的一个配置项，具体位置有注释说明。
再具体的结构和代码这里就不多讲了，如果感兴趣，可以下载webappdemo看看，里面的注释比较完整。不过在demo里还有一些隐藏问题，以及可以扩展的思路，不知道你能不能找出来。
尾声老话说，条条大路通罗马，在开源的java的世界更是如此，我们可以有自己的想法并且拿出来分享，这就是开源最大的魅力，也是资源的宝库。尽管sun被收购，但是java仍然会是开源最响亮的声音，javafx是笔者目前最关注的技术，希望他能一路走好。
1 楼 sunbin123 2012-01-01 是不是忘记添加webappdemo这个demo了？希望lz补上，谢谢