"解耦"的思想一直是我们倡导的,但在实际项目中怎样去做?这是需要我们去好好思考的。下面以Model1、Model2、三层为切入点，对比下去了解解耦的思想。
(图是网上找的，画图太繁琐，见谅)
Model1
使用JSP页面和JavaBean相结合的方式，由JSP页面来接收客户端请求，用JavaBean或其他服务完成业务逻辑、数据库操作和返回页面。我们这里的JavaBean主要是完成特定功能的Java类。
优点：架构简单，比较适合小型项目开发
缺点：JSP职责不单一，职责过重，不便于维护
Model2（MVC）
Model1虽然在一定程度上解耦了，但JSP依旧即要负责页面控制，又要负责逻辑处理，职责不单一。此时Model2应运而生，使得各个部分各司其职。 Model2基于MVC模式:
Controller：应用程序中用户交互部分（Servlet）
Model：应用程序数据逻辑部分（JavaBeans）
View：数据显示部分（JSP）
优点：职责清晰，较适合于大型项目架构
缺点：分层较多，不适合小型项目开发
区别：
Model2在Model1的基础上分离了控制，将JSP中的逻辑操作部分分离出来，这样做不仅减轻了JSP的职责，而且更有利于分工开发，耦合性降低。
对于复杂的Web应用开发，更适合使用Model2；而对于小型应用，使用Model1比较简单。
三层
Model2巧妙的将JSP中的业务逻辑部分分给了Servlet，使得页面控制与逻辑处理彻底分离，达到了部分解耦的目的。但我们现实项目开发中，往往在Model2的基础上又进行了分层。将业务逻辑细分为业务逻辑和持久化逻辑两层。
往往使用一个Dao接口隐藏持久化操作的细节，业务对象不需要了解底层的数据库持久化知识。使得业务逻辑与持久化逻辑分离，业务逻辑通常关系的是应用程序的核心流程和业务规则，持久化逻辑关注的是如何访问和操作持久化数据。
表示层，JSP/Servlet
业务逻辑层：业务规则
持久化层：主要包装持久化的逻辑
分层主要目的是为了好管理，能更好的适应需求的变换，能够更好的进行人员分工。
表示层、业务逻辑层、持久层是自上而下的依赖，依赖于抽象
程序对JDBC的依赖就是依赖了他的抽象层，如：连接数据库用的Connection，我们只能看到其接口，而不能看到其实现，具体的实现封装在JDBC包中。JDBC已经包装好，我们只需要引入不同实现，以适应数据库的变化。
总结：
Model1、Model2、三层是在解耦的基础上一步步进化而来，通过解耦我们可以进行进一步的抽象，以应对现实需求的变动。