（一）一层架构模式
最简单的方法就是直接使用JSP文件进行所有功能的开发。用户的请求发送给JSP 文件，响应也有JSP文件完成。 如图 1 所示：
这种模式的好处是：对于程序学习者来说逻辑比较简单，容易理解，开发速度快。通常用于简单的Web网站开发。它的缺点是：当功能复杂时，代码的可读性差。因此此种方法没有被业界给出什么明确的定义。
（二）两层架构模式Model1
为了解决一层架构的代码可读性差的问题，我们将大量的Java代码抽取出来放在JavaBean组件中，由JSP页面调用JavaBean组件完成业务操作，而用户的请求和响应同样还是由JSP文件完成。如图2所示，是两层模式的结构图，术语称作Model1模式。
Model1是一个以JSP文件为中心的模式，在这种模式中JSP页面不仅负责表现逻辑，也负责控制逻辑，其业务逻辑由JavaBean来实现。专业书籍上称之为逻辑耦合在页面中，这种处理方式，对一些规模很小的项目，如一个简单的留言簿，也没什么太大的坏处。实际上，人们开始接触一些对自己来说是新的东西的时候，比如，用JSP访问数据库时，往往喜欢别人能提供一个包含这一切的单个JSP页面，因为这样在一个页面上他就可以把握全局，便于理解。但是，用Model1模式开发大型项目时，程序流向由一些互相能够感知的页面决定，当页面很多时要清楚地把握其流向将是很复杂的事情，当您修改一页时可能会影响相关的很多页面，大有牵一发而动全身的感觉，使得程序的修改与维护变得异常困难；还有一个问题就是程序逻辑开发与页面设计纠缠在一起，既不便于分工合作也不利于代码的重用，这样的程序其健壮性和可伸缩性都不好。
（三）三层架构模式Model2
为了 克服 Model 1 的 缺陷， 人们 引入 了 三层 架构 的 Model 2 模式， 如图 3 所示：
Model2模式引入了“控制器”这个概念，控制器一般由Servlet来担任，客户端的请求不再直接送给一个处理业务逻辑的JSP页面，而是送给这个控制器，再由控制器根据具体的请求调用不同的事务逻辑，并将处理结果返回到合适的页面。因此，这个Servlet控制器为应用程序提供了一个进行前后端处理的中枢。一方面为输入数据的验证、身份认证、日志及实现国际化编程提供了一个合适的切入点，另一方面也提供了将业务逻辑从JSP文件剥离的可能。业务逻辑从JSP页面分离后，JSP文件蜕变成一个单纯完成显示任务的显示层，这就是常说的Viewer。而独立出来的事务逻辑变成人们常说的Model，再加上控制器Controller本身，就构成了MVC模式。实践证明，MVC模式为大型程序的开发及维护提供了巨大的便利。MVC设计模式很清楚地划定了程序员与设计者的角色界限。换句话说，从商业逻辑上拆解了数据。这种模式是让设计者集中于设计应用程序的显示部分，而开发者则集中于开发驱动应用程序功能所需的组件。
（四）多层架构模式
J2EE三层结构的划分当然是经典的，但是在实际项目中，往往会对三层体系结构做一些扩展来满足项目的需要。一个最常用的扩展就是将三层体系扩展为四层体系，即表示层（Viewer）、控制层（Controller）、服务层（DAO）和数据持久层（DataPersistence）。它其实是将三层架构中的模型层进行了拆分，服务层用于操作持久层进行数据操作，数据持久层表示数据库的持久内存存储对象。如图4所示。
由于Java开源项目的发展，J2EE的多层架构中的每一层都有许多的开源软件可以使用。例如：
● 控制层：Struts、Spring、Webwork、JSF、Tapestry、Turbine等；
● 显示层：StrutsTiles、JSTL、Velocity、FreeMarker、XSLT等；
● 数据持久层： Hibernate
、
Ibatis
等。将上面的各层技术随意组合便可以构建一个
J2EE
的多层开发架构。
