mybatis配置文件中,parameterType、resultType、resultMap三者有什么区别?
parameterType是在mapperxml文件CRUD进行传参的属性,可以不指定!
MyBatis中在查询进行select映射的时候,返回类型可以用resultType,也可以用resultMap,resultType是直接表示返回类型的,
而resultMap则是对外部ResultMap的引用,但是resultType跟resultMap不能同时存在。
在MyBatis进行查询映射时,其实查询出来的每一个属性都是放在一个对应的Map里面的,其中键是属性名,值则是其对应的值。
① 当提供的返回类型属性是resultType时,MyBatis会将Map里面的键值对取出赋给resultType所指定的对象对应的属性。
所以其实MyBatis的每一个查询映射的返回类型都是ResultMap,只是当提供的返回类型属性是resultType的时候,
MyBatis对自动的给把对应的值赋给resultType所指定对象的属性。
② 当提供的返回类型是resultMap时,因为Map不能很好表示领域模型,就需要自己再进一步的把它转化为对应的对象,这常常在复杂查询中很有作用。
在mybatis中映射文件中的namespace有什么作用?
在mybatis中,映射文件中的namespace是用于绑定Dao接口的,即面向接口编程。
当你的namespace绑定接口后,你可以不用写接口实现类,mybatis会通过该绑定自动
帮你找到对应要执行的SQL语句
如下:
假设定义了IArticeDAO接口
public interface IArticleDAO
{
List
}
对于映射文件如下:
SELECT t.* FROM T_article t WHERE t.flag = ‘1’ ORDER BY t.createtime DESC
MyBatis缓存优缺点
优点:
- 易于上手和掌握。
- sql写在xml里,便于统一管理和优化。
- 解除sql与程序代码的耦合。
- 提供映射标签,支持对象与数据库的orm字段关系映射
- 提供对象关系映射标签,支持对象关系组建维护
- 提供xml标签,支持编写动态sql。
缺点: - sql工作量很大,尤其是字段多、关联表多时,更是如此。
- sql依赖于数据库,导致数据库移植性差。
- 由于xml里标签id必须唯一,导致DAO中方法不支持方法重载。
- 字段映射标签和对象关系映射标签仅仅是对映射关系的描述,具体实现仍然依赖于 sql。
(比如配置了一对多Collection标签,如果sql里没有join子表或查询子表的话,
查询后返回的对象是不具备对象关系的,即Collection的对象为null) - DAO层过于简单,对象组装的工作量较大。
- 不支持级联更新、级联删除。
- 编写动态sql时,不方便调试,尤其逻辑复杂时。
8 提供的写动态sql的xml标签功能简单(连struts都比不上),编写动态sql仍然受限,且可读性低。 - 若不查询主键字段,容易造成查询出的对象有“覆盖”现象。
- 参数的数据类型支持不完善。(如参数为Date类型时,容易报没有get、set方法,需在参数上加@param)
- 多参数时,使用不方便,功能不够强大。(目前支持的方法有map、对象、注解@param以及默认采用012索引位的方式)
- 缓存使用不当,容易产生脏数据。
mybatis和hibernate的区别
前者是半自动的,hibernate是全自动的
前者是把sql语句与java代码分离了,sql配置到xml文件中
hibernate是orm框架,他对jdbc进行了封装,在分层结构中处于持久化层
他能建里面向对象的与模型和关系数据模型之间的映射
他大大简化了dao层的编码工作
mybatis 中$ 和 #的区别?
#传入的数据,在mysql中会被当成字符串,自动加个双引号,很大程度防止sql注入,安全的。
传
入
的
数
据
会
直
接
显
示
在
s
q
l
中
,
一
般
传
数
据
库
对
象
(
列
名
)
,
它
不
能
防
止
s
q
l
的
注
入
,
不
安
全
。
M
y
B
a
t
i
s
排
序
时
使
用
o
r
d
e
r
b
y
动
态
参
数
时
需
要
注
意
,
用
传入的数据会直接显示在sql中,一般传数据库对象(列名),它不能防止sql的注入,不安全。 MyBatis排序时使用order by 动态参数时需要注意,用
传入的数据会直接显示在sql中,一般传数据库对象(列名),它不能防止sql的注入,不安全。MyBatis排序时使用orderby动态参数时需要注意,用而不是#;