方法一
- Dao 层有一对多、一对一关联
- Service 层写业务逻辑
方法二
- Dao 层不写一对多、一对一关联,只提供基本的增删查改
- Service 层完成关联查询等以及写业务逻辑
方法一在效率上貌似有优势,但写 resultMap 和语句真是不开心
方法二对程序员比较友好,但效率不如方法一,而且 service 层会比较臃肿
不知道大家的项目中都是如何使用的
PS:临时从 Android 调到 Web 这边帮忙, web 技术并不精通,还请大家多多指教
方法一在效率上貌似有优势,但写 resultMap 和语句真是不开心
方法二对程序员比较友好,但效率不如方法一,而且 service 层会比较臃肿
不知道大家的项目中都是如何使用的
PS:临时从 Android 调到 Web 这边帮忙, web 技术并不精通,还请大家多多指教
|
zts1993Oct 26, 2015
1
不知道。。。我感觉看心情。简单的可以关联一下。。数据量大,感觉就不能这么玩了。。
|
|
zkaipOct 26, 2015
2
我是主要在 service 层写逻辑, dao 层只简单的做一些关联查询
|
|
3
一般在实际开发中我们都使用的是方法一,因为这样子比较适合多人开发吧。而且基本的增删改查可以使用 mybatis 的 xml 文件自动生成的。
resultmap 有个好处是需要什么数据就拿什么数据,不怎么需要 vo 层了。 |
|
4
@Lpl 感谢,知道咋弄拉
|
|
5
@Lpl 还有一个问题请教一下噢,比如我现在存在以下对应关系
* 班级 一对多 学生 * 学生 一对多 科目 * 科目 一对一 老师 那么我需要在查询班级的时候直接把 班级对应学生 学生对应科目 科目对应老师 的**resultMap**都写好然后再写好查询`SQL`语句么 那如果有很复杂的对应关系的时候会不会比较麻烦额。。 |
|
6
单表的查询都是用 mybatis generator 生成 xml,bean 之类的代码,虽然用起来比较啰嗦但是还是还是挺好用的.
多表查询就得自写 xml 的 sql 了以及自设的结果集了,关联查询用 join 感觉还是挺方便的. |
|
thinkmoreOct 27, 2015
7
多对多好麻烦。如果需要这种直接关联查询出来之后,然后在组装到对应的实体类中去不就行了,当然这里组装麻烦了一点点吧。
数据量小的情况下还是建议多对多的 |
|
8
@domty 感谢回答,目前我采取的也是这种方式😄
|
|
9
@thinkmore 确实,我也觉得这种情况下写 SQL 还是比较麻烦的。。
|
|
10
一般都多表 join 返回对象 数据库没有做关联 - - 都是单表自己写 sql
|
|
11
一般都多表 join 返回对象 数据库没有做关联 - - 都是单表自己写 sql + 1
|
|
12
@loshine1992 按照我们是这样子做的,把三张表写 sql 语句,使用 left join 取出来一些你需要的列放在 resultmap 中
|
|
LplOct 27, 2015 via Android
13
left join 类似的有坑...我记得当时踩过,然后忘了,就是在一对多的时候出现的
|
|
14
@Lpl 感谢回复,其实已经使用这种方式了,就是不太喜欢这种机械式的劳作。。。。
|
|
LplOct 27, 2015 via Android
15
@loshine1992 但是这种是比较好的方式。有一点,你们是不是在数据库中显式定义 foreign key 了?这样子不好
|
|
16
@Lpl 没有显式定义外键的,这个在项目启动的时候我就和后端的负责人建议过。
目前其实有一个比较糟糕的情况,因为后端的负责人之前不太了解 Spring MVC 和 Mybatis 所以现在的代码是比较不规范的 比如 Controller 层中大量使用了 request.addAttribute(key,value) 而非 modelMap.put(key, value),返回 json 也是直接操作的 response 最为麻烦的其实是。。他手写了 dao 层的实现而没有使用 Spring 扫描 Mybatis 的代理实现方式。。。。。。。 |
|
LplOct 28, 2015 via Android
17
@loshine1992 你们后端负责人为什么不听建议...
|