我决定尝试将mybatis用于新项目。我对SQL非常熟悉,最近我对hibernate有一些不好的经历,所以我正在寻找一种更低级的DAO方法。
除了一件事,似乎相当不错,那就是处理集合。
我有两个POJO,组和用户,它们是多对多的。我已经决定了一个设计理念,即拥有集合的POJO应该只在保存时更新表之间的M-M关系。因此,例如,当我保存具有用户集合的组对象时,设计理念规定应该已经保存用户,并且我只需要将数据库和group_user关系保存在数据库中。
所以,对于界面中的saveGroup函数,我为mybatis做了这个XML映射:
<insert id="saveGroup" keyColumn="id"
parameterType="se.myapp.domain.Group">
<choose>
<when test="id == null">
INSERT INTO myapp_group (name, description)
VALUES
(#{username}, #{password});
</when>
<otherwise>
UPDATE myapp_group set name=#{name}, description=#{description}
where id=#{id};
</otherwise>
</choose>
<if test="users != null">
create temporary table tmpnewgroups (group_id integer, user_id integer);
insert into tmpnewgroups (group_id, user_id) values (
<foreach collection="users" item="user" open="" close="" separator="),()">
#{id},#{user.id}
</foreach>
);
insert into myapp_user_group(group_id, user_id)
select tmp.group_id, tmp.user_id
from tmpnewgroups tmp
left outer join myapp_user_group ug
on ug.group_id = tmp.group_id and ug.user_id = tmp.user_id
where ug.group_id is null;
delete from myapp_user_group
where group_id = #{id} and user_id not in (select user_id from tmpnewgroups);
</if>
</insert>
这确实按预期工作(插入/更新组,将用户集合保存为数据库中的关系)。但我并不觉得这是最好的做法。应用程序是为了在需要时可以切换到休眠状态,因此保存集合的逻辑最好应该在数据库层中。 mybatis中是否有一些“神奇”,我不知道这可以简化这样的操作?
有关如何改善这一点的任何想法?或者我应该重新考虑应用程序设计并将集合的处理进一步放在模型中吗?
答案 0 :(得分:2)
saveGroup数据映射操作的第二部分确实是重新考虑应用程序设计的一个原因。将内存中用户集合保留到临时表以将其与持久表进行比较以插入和删除增量是一项相当繁重的操作,如果只需要更新组的名称或描述,则根本不需要即没有增量时。是否是这种情况可以由数据库服务器(您当前的解决方案)或数据库客户端(您的应用程序)决定。
除了组和可能的用户需要首次插入的情况之外,如果您希望应用程序决定是否需要更新链接表,那么您的应用程序需要知道用户是否收集自从数据库中检索后发生了变化。不幸的是,MyBatis不会帮助您的应用程序这样做。
请参阅,与Hibernate相比,MyBatis在MyBatis完成其工作(即数据映射,而不是对象关系映射)之后,幸福地不知道您的对象及其携带的状态。 Hibernate可以自动检测对象的所谓脏状态,MyBatis不能,因为这从未成为其工作描述的一部分。所以你只能使用自己的设备。
一种超级简单的方法是在选择之后存储用户的哈希码,并使用名为isUserDirty()
的方法检查该哈希码是否已更改。您只需使用<if test="isUserDirty">
在映射中测试该条件即可。这当然不是一种非常通用的方法,取决于一个体面的hashCode()实现。对于类似的问题,请查看leonbloy的answer以获得更通用的方法。当然,这可能仍然有点过于简单,特别是因为我们正在谈论多对多的关系。哪种方法最好都取决于您的情况。
现在你应该知道该怎么做了。祝你好运!
PS而不是插入和删除delta我会建议一个简单的覆盖:删除所有然后在事务中插入所有。您的临时表策略是一种优化策略,实际上可能根本不会提高数据库的性能,实际上我的猜测是它可能会使情况变得更糟。如果你已经正确地描述了这个策略并知道你正在做什么,你可以忽略这个后记。