yyyyyyyi
2014-01-14 11:43 阅读 267
已采纳

持久化工具ibatis的问题

使用ibatis了小半年,没有接触过其他持久化工具,听说过著名的h持久化工具,没有使用过。暂时觉得ibatis非常简单,灵活。但也发现了问题,不知道是不会用,还是想法本身的问题。

产品研发期间使用ibatis自带工具对数据库进行映射生成(dao,service,pojo),个人理解持久化这层就是dao这层,service与pojo已经算业务层。
业务逻辑都写在service里,方便事务控制回滚,排他。项目将业务逻辑和持久化这两层单独提出来,进行了rest封装,方便其他平台调用。同时展示层有两套方案分别用的传统html5+ajax,另一套是服务器端动态生成ui的框架。

业务层的疑问????
由于ibatis自动生成(dao,service,pojo),所以生成出来的是以面向对象为主体,数据关系被淡化了。也就是每一个对象有一套自己service和dao进行数据操作,当我新增业务时,我首先是找到该业务的主体操作对象,然后到该对象的对应service上新增业务逻辑,然后可能会调用到多个其他对象对应的dao进行多个对象的数据操作。关于业务这块,我想到了几个解决办法,不知道哪种更可取

1:service还是以对象的这种方式生成,当我新增业务时,首先是找到该业务的主体操作对象,然后到该对象的对应service上新增业务逻辑,调用多个其他对象对应的dao。service绝不调用其他service。

2:对象对应着的service不变,当新增业务时,新建service类,调用其他对象对应的service处理业务逻辑。

3:对象对应着的service不变,当新增业务时,新建service类,调用其他对象对应的dao处理业务逻辑,绝不调用其他service。

持久化层的疑问????
由于项目所需的表在数据库级别没有建立任何约束,所有关系都依靠代码控制,也就是dao这层来控制。我将持久化操作分为两类:一类是查询,一类是非查询。

查询:多表关联查询时,重写ibatis对象对应的sql ,争取一个sql查出所有数据,后来发现随着业务增加,关联的越来越多,而且方向都不尽相同,只能拆分成多个查询方法,以提供给service调用。
非查询:service控制,事务控制,一个对象一个对象的处理,直到全部搞定。

目前是这样解决的,但是总感觉sql很乱,风格不统一,不知道有没有啥好方法

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

4条回答 默认 最新

  • 已采纳
    hellostory hellostory 2014-01-15 13:33

    看了楼主的问题,有几点感慨:

    [color=blue]① 感觉楼主纯粹就是为分层而分层,根本没有理解为什么要分层!

    ② IBatis就是一个持久层的工具,不知道为什么你还要让它自动生成业务层Service的东西?

    ③ Service层的对象是业务对象,不是简单的Java POJO对象。楼主一直把IBatis层的对象和Service层的对象混为一谈,才会这么迷惑!不知道我有没有说错?

    ④ Service层的对象只能调用Service层的对象,DAO层的对象只能调用DAO层的对象!这是基本原则,要不我们还有分层干嘛?
    比如:
    1)DAO层的UserMapper.findById()返回的User对象只包含:工号、姓名、年龄
    2)Service层的UserMapper.findById()返回的User对象不仅包含:工号、姓名、年龄,还包含所属部门、拥有的角色列表……[/color]
    [color=red] 注意:这里Service层的User对象可不是DAO层的User对象!这就是你一直混淆的地方之一! [/color]

    点赞 评论 复制链接分享
  • iteye_6244 iteye_6244 2014-01-14 17:44

    如果是我的话,我会一个业务对象一个service,然后service调用多个DAO,DAO层应该只做数据的查询和存储,不涉及业务逻辑。
    如果一个service里面的代码太多了的话,再根据业务再细分。
    一个对象一个对象的存储数据不是条理很清晰吗?修改起来也只需要修改相对较小的SQL段。为了条理性,牺牲一点性能也是可以接受的。如果全部的逻辑都在一块,后续的修改只会让代码越来越难以维护。

    点赞 评论 复制链接分享
  • iteye_2866 iteye_2866 2014-01-15 11:09

    大量程序生搬硬套分层思想,说下我目前项目的分层

    对于一般简单业务如只有CRUD在action中,直接用sqlsession调用sql xml,参数都是Map,不是java bean,自己写了一个ParameterInterceptor把request的参数,变成一个Map,
    在action中直接传入sql中,

    对于烦点的业务,要有事务,才会建xxxxService,不过在service类中还用sqlssesion直接调用各个sql,基本保持每个mapping xml文件只有一个表的相关sql,

    关于java bean我们是分两种一种vo是对应页面表单,一种pojo对应DB表结果 ,常常有这种代码xxxVo.getUser 得到一个pojo对应 然后再xxxVo.getDept 再得到一个pojo,把pojo给sql mapping.

    dao层我们基本没有,只有二三个表的操作有对应的dao类,那是因为这几个表都做了分表,不是一张物理表,是多张表,

    可能有人问,你们action层中怎么搞事务,我们action根本就没事务管理,action基本都是
    就一行insert ,update,delete要什么事务,别给数据库增加压力

    希望对你有用

    点赞 评论 复制链接分享
  • iteye_2866 iteye_2866 2014-01-15 11:22

    和原来老项目比了下 老项目就是action,service,dao,每个业务都样这样
    老项目 java文件数量871个 1.9M大小
    现在我建立的新项目java文件数量197个 551 KB

    点赞 评论 复制链接分享

相关推荐