本文为《Spring + MyBatis 企业应用实战》章节笔记
1.1 Java EE 应用概述
1.1.1 Java EE 应用的分层模型
-
Domain Object
(领域对象)层由一系列的 POJO 组成,包含了各自所需实现的业务逻辑方法
-
DAO
(Data Access Object,数据访问对象)层由一系列的 DAO 组件组成,它们实现了对数据库的创建、查询、更新和删除(CRUD)等原子操作
-
Service
(业务逻辑)层由一系列的业务逻辑对象组成,实现了系统所需要的业务逻辑方法
-
Controller
(控制器)层由一系列的控制器组成,用于拦截用户请求,并调用业务逻辑组件的业务方法,处理用户请求,并根据处理结果向不同的表现层组件转发
-
View
(表现)层由一系列的 JSP 页面、Velocity 页面、PDF 文档视图组件组成,负责手机用户请求,并显示处理结果
各层的 Java EE 组件之间以松耦合的方式耦合在一起,各组件并不以硬编码方式耦合,这种方式是为了应用以后的拓展性。从上向下,上面组件的实现依赖于下面组件的功能;从下向上,下面组件支持上面组件的实现。
1.12 Java EE 应用的组件
-
表现层组件
负责收集用户输入数据,或者向用户显示系统状态。
-
控制器组件
对于 Java EE 的 MVC 框架,其提供一个前端核心控制器,负责拦截用户的请求,并将请求转发给用户实现的控制器组件。用户实现的控制器组件则负责调用业务逻辑方法,处理用户请求。
-
业务逻辑组件
系统的核心组件,实现系统的业务逻辑。一个业务逻辑方法对应一次用户操作。一个业务逻辑应该是一个整体,因此要求对业务逻辑方法增加事务性。业务逻辑方法仅仅负责实现业务逻辑,不应该进行数据库访问。
-
DAO 组件
每个 DAO 组件都提供 Domain Object 对象基本的创建、查询、更新和删除等操作,这些操作对应于数据库的 CRUD 原子操作。为了业务逻辑组件的实现和 DAO 组件的实现分离,程序应该为每个 DAO 组件都提供接口,业务逻辑组件面向 DAO 接口编程,这样才能更好的解耦。
-
领域对象组件
抽象了系统的对象模型。通常而言,这些领域对象的状态都必须保存在数据库里,领域对象需要提供对数据记录的访问方式。
1.2 轻量级 Java EE 应用相关技术
1.2.1 JSP、Servlet 和 JavaBean 及替代技术
1.2.2 MyBatis 及替代技术
本书用版本为 3.4.1。
MyBatis 作为持久层框架,其主要思想是将程序中的大量 SQL 语句剥离出来,配置在配置文件中,实现 SQL 的灵活配置。这样做的好处是将 SQ 了与程序代码分离,可以在不修改程序代码的情况下,直接在配置文件中修改 SQL。
MyBatis 与 Hibernate 的区别
-
Hibernate 是全自动,而 Mybatis 是半自动。
hibernate 完全可以通过对象关系模型实现对数据库的操作,拥有完整的 JavaBean 对象与数据库的映射结构来自动生成 sql。而 mybatis 仅有基本的字段映射,对象数据以及对象实际关系仍然需要通过手写 sql 来实现和管理。
-
Hibernate 数据库移植性远大于 Mybatis。
Hibernate 通过它强大的映射结构和 SQL 语言,大大降低了对象与数据库(Oracle、MySQL 等)的耦合性,而 Mybatis 由于需要手写 sql,因此与数据库的耦合性直接取决于程序员写 SQL 的方法,如果 SQL 不具通用性而用了很多某数据库特性的 SQL 语句的话,移植性也会随之降低很多,成本很高。
-
Hibernate 拥有完整的日志系统,Mybatis 则欠缺一些。
Hibernate 日志系统非常健全,涉及广泛,包括:SQL 记录、关系异常、优化警告、缓存提示、脏数据警告等;而 Mybatis 则除了基本记录功能外,功能薄弱很多。
-
mybatis 相比 hibernate 需要关心很多细节
Hibernate 配置要比 Mybatis 复杂的多,学习成本也比 Mybatis 高。但也正因为 Mybatis 使用简单,才导致它要比 Hibernate 关心很多技术细节。 Mybatis 由于不用考虑很多细节,开发模式上与传统 jdbc 区别很小,因此很容易上手并开发项目,但忽略细节会导致项目前期 bug 较多,因而开发出相对稳定的软件很慢,而开发出软件却很快。 Hibernate e 则正好与之相反。但是如果使用 Hibernate 很熟练的话,实际上开发效率丝毫不差于甚至超越 Mybatis 。
-
sql 直接优化上,mybatis 要比 hibernate 方便很多
由于 Mybatis 的 sql 都是写在 xml 里,因此优化 sql 比 Hibernate 方便很多。而 Hibernate 的 sql 很多都是自动生成的,无法直接维护 sql;虽有 hql,但功能还是不及 sql 强大,见到报表等变态需求时,hql 也歇菜,也就是说 hql 是有局限的; Hibernate 虽然也支持原生 sql,但开发模式上却与 orm 不同,需要转换思维,因此使用上不是非常方便。总之写 sql 的灵活度上 Hibernate 不及 Mybatis 。
总结:
-
mybatis:小巧、方便、高效、简单、直接、半自动
-
hibernate:强大、方便、高效、复杂、绕弯子、全自动
Mybatis:
-
入门简单,即学即用,提供了数据库查询的自动对象绑定功能,而且延续了很好的 SQL 使用经验,对于没有那么高的对象模型要求的项目来说,相当完美。
-
可以进行更为细致的 SQL 优化,可以减少查询字段。
-
缺点就是框架还是比较简陋,功能尚有缺失,虽然简化了数据绑定代码,但是整个底层数据库查询实际还是要自己写的,工作量也比较大,而且不太容易适应快速数据库修改。
-
二级缓存机制不佳。
Hibernate:
-
功能强大,数据库无关性好,O/R 映射能力强,如果你对 Hibernate 相当精通,而且对 Hibernate 进行了适当的封装,那么你的项目整个持久层代码会相当简单,需要写的代码很少,开发速度很快,非常爽。
-
有更好的二级缓存机制,可以使用第三方缓存。
-
缺点就是学习门槛不低,要精通门槛更高,而且怎么设计 O/R 映射,在性能和对象模型之间如何权衡取得平衡,以及怎样用好 Hibernate 方面需要你的经验和能力都很强才行。
举个形象的比喻:
mybatis:机械工具,使用方便,拿来就用,但工作还是要自己来作,不过工具是活的,怎么使由我决定。
hibernate:智能机器人,但研发它(学习、熟练度)的成本很高,工作都可以摆脱他了,但仅限于它能做的事。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于