解耦的思想一直是我们倡导的,但在实际项目中怎样去做,这是需要我们去好好思考的。下面以 Model1、Model2、三层为切入点,对比下去了解解耦的思想。

Model1 模式

使用 JSP 页面和 JavaBean 相结合的方式,由 JSP 页面来接收客户端请求,用 JavaBean 或其他服务完成业务逻辑、数据库操作和返回页面。我们这里的 JavaBean 主要是完成特定功能的 Java 类。

11.png

优点:架构简单,比较适合小型项目开发
      
缺点:JSP 职责不单一,职责过重,不便于维护

Model2(MVC)开发模式

 
Model1 虽然在一定程度上解耦了,但 JSP 依旧即要负责页面控制,又要负责逻辑处理,职责不单一。此时 Model2 应运而生,使得各个部分各司其职。  Model2 基于 MVC 模式:

Controller:应用程序中用户交互部分(Servlet)

Model:应用程序数据逻辑部分(JavaBeans)

View:数据显示部分(JSP)
12.png

优点:职责清晰,较适合于大型项目架构          

缺点:分层较多,不适合小型项目开发

区别:

Model2 在 Model1 的基础上分离了控制,将 JSP 中的逻辑操作部分分离出来,这样做不仅减轻了 JSP 的职责,而且更有利于分工开发,耦合性降低。

对于复杂的 Web 应用开发,更适合使用 Model2;而对于小型应用,使用Model1 比较简单。

三层 开发模式

 
Model2 巧妙的将 JSP 中的业务逻辑部分分给了 Servlet,使得页面控制与逻辑处理彻底分离,达到了部分解耦的目的。但我们现实项目开发中,往往在 Model2 的基础上又进行了分层。将业务逻辑细分为业务逻辑和持久化逻辑两层。

往往使用一个 Dao 接口隐藏持久化操作的细节,业务对象不需要了解底层的数据库持久化知识。使得业务逻辑与持久化逻辑分离,业务逻辑通常关系的是应用程序的核心流程和业务规则,持久化逻辑关注的是如何访问和操作持久化数据。

表示层,JSP/Servlet

业务逻辑层:业务规则

持久化层:主要包装持久化的逻辑 

分层主要目的是为了好管理,能更好的适应需求的变换,能够更好的进行人员分工。

表示层、业务逻辑层、持久层是自上而下的依赖,依赖于抽象

13.png

程序对 JDBC 的依赖就是依赖了他的抽象层,如:连接数据库用的 Connection ,我们只能看到其接口,而不能看到其实现,具体的实现封装在 JDBC 包中。 JDBC 已经包装好,我们只需要引入不同实现,以适应数据库的变化。

总结:

Model1、Model2、三层是在解耦的基础上一步步进化而来,通过解耦我们可以进行进一步的抽象,以应对现实需求的变动。

14.png