java web框架的分层_Java Web 框架：我对架构中分层的理解

J2EE 世界充斥着许多概念，如 MVC、Service、DAO 等等，而且这些许多都是“似是而非”的名词。如果不对这些概念进行厘清，恐怕不能全然贯通、明晰整个框架。这就体现了概念其重要性。鄙人希望：一、概念虽然会比较”笼统“，——这是因为概念处于较高层的位置，有涵盖的作用，但应该尽量明晰和收窄定义的范围；二、从概念到某件事物，是”抽象“到”具象“的过程，会形成某个特定”名词“，既然”名词“是特指的，那么应该没有二义性，即没有歧义；三、概念最后能找到真正所对应的具体事物，可以在代码中反映出来的。凡事须顾名思义，有其名就当有其实；四、理想情况下，一个系统不应存在重复的代码或模块。如果赋予一个事物有一个概念或名词 A，A 具有排他性，不能再使用，但可以包含其所属的 B 事物。即，A 是 A，B 是 B。如果 A 包含 B，那么 A ≠ B。

需要指出的是，本文所讨论的定义对其他框架不一定适用，请不要周延，当前仅限于 Bigfoot 界定概念所用——这也是为了避免争议的提前声明，同时这样也比较简单，点到即止。

基础概念

分层是应对复杂性的必然手段。解决一个个各自的小问题，最终来解决大问题，“分而治之”。

程序三层结构，毋庸置疑。

与数据库打交道的三个方法

我们比较推崇“半自动 SQL”的方法，既非直接写 SQL，也不是 ORM(也不熟悉 存储过程)。此方面的具体内容，参见前篇文章《浅浅地封装一层 JDBC》。

一般 SSH 结构

虽然有经典 SSH 架构摆在面前，但我们并不拘泥于此，同样积极寻找适应项目变化，可重用，方便程序员的架构方法，以适应于“互联网程序架构”而非单单“企业级开发”的架构。

项目结构

可维护的结构

MVC 是个大领纲，不同的框架对 MVC 的理解和实践都不尽相同，有时候甚至很难一一对号入座，也有许多衍生分支的版本。实际上，MVC 是一种模式，模式不是公式，所以除了必要的条件限定之外，就没有一定的条条框框。

注意，前面说到的三层架构 ≠ MVC。

除了经典的 JSP + Bean + Servlet 架构外，还有一种更为简单的 JSP + Bean 模式。两者区别在于处理的主控部分不同。前者利用Servlet作为主控部分；后者利用JSP作为主控部分，将用户的请求、Bean 和事件响应有效的连接起来。

我比较倾向于 JSP + Bean 模式。该模式工作原理是：当 HTTP 发出请求时，JSP 接收请求并访问 Bean，当需要访问数据库或者服务器时，则通过  Bean 做相应处理。Bean 将处理的结果返回 JSP，JSP 生成动态 html 将结果传送到浏览器并显示，用户得到交互结果。JSP 作为视图，同时也有部分控制器的功能， Bean 组件作为模型和控制器组件。

这样的好处是首先不用配置 Servlet，一个 JSP 即是 Servlet(请求路径多起来维护麻烦)，其次是JSP以显示为中心，它为Web前端开发提供了更方便的开发。再者是仍然可以做到显示和内容分离，显示和业务逻辑开发可以分开同时进行，实际上并不会在 JSP 嵌入大量 Java 代码，而且显得更简单。

必须提出的是，纯 service 接口的话应该使用 Bean + Servlet 的模式，那是完全排除表示层的考虑。

前端分层，围绕 HTML、CSS、JS 三大模块来处理。

模板技术我主张使用 Tag Files。有关 Tag Files 的更多教程，参见本博客《JSP Tag Files 技术总结》

项目选型

经过反复使用和衡量，决定采用下面的组件。分有前端和后端的(点击图片放大)。

前端堆栈我的方案如下：