持久化工具ibatis的问题

0 0

持久化工具ibatis的问题0

使用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很乱，风格不统一，不知道有没有啥好方法

iBATIS 设计持久化

2014年1月14日 11:43

woaichiyu
1
0 0 11

4个答案按时间排序按投票排序

0 0

采纳的答案

看了楼主的问题，有几点感慨：

① 感觉楼主纯粹就是为分层而分层，根本没有理解为什么要分层！

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

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

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

2014年1月15日 13:33

hellostory
32
1 1 8

7条评论

0 0

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

2014年1月15日 11:22

blackstreet
30
0 1 1

添加评论

0 0

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

对于一般简单业务如只有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要什么事务，别给数据库增加压力

希望对你有用

2014年1月15日 11:09

blackstreet
30
0 1 1

3条评论

0 0

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

2014年1月14日 17:44