架构论文.doc

2009-10-27 可爱的javaee：非框架架构漫谈 JavaEE框架SQLJSPMobile 概述 你可以说可爱的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)选择控制器 基础规范的不足 任何web应用，处理请求之后返回响应是必须的环节，如果编码规范，传统的响应就是转向到某个页面，servlet处理转向有两种方式，其中request转向隐藏着重复提交的问题，response重定向带来参数传递的编码解码的问题，同时众多的转向地址直接写在servlet中也十分不雅，另外，jsp和javabean有一种出色的关联技术，就是在jsp里可以把来自请求表单的数据通过标签自动拼装到javabean中。糟糕的是，这么有用的技术却无法在servlet中使用，所以Model2缺乏对表单数据的自动转换处理。servlet有这些不足很好理解，因为servlet毕竟是较早出现的技术，他的职责只是将（http）请求转化为面向对象的视图和输出响应而已，由于他是低阶组件，所以部分功能的缺失是正常的。不过这就让servlet成为了Model2最薄弱的一环。 开发框架的解决方案 由于以上需求是共性的，所以编写一个通用框架就成为了很多人努力的事情，struts很快推出并且很快流行。我们先来看一看struts的特性： 前端控制器：struts使用一个servlet作为前端控制器，所有请求先经过这