问题描述
使用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就是一个持久层的工具，不知道为什么你还要让它自动生成业务层Service的东西？③ Service层的对象是业务对象，不是简单的Java POJO对象。楼主一直把IBatis层的对象和Service层的对象混为一谈，才会这么迷惑！不知道我有没有说错？④ Service层的对象只能调用Service层的对象，DAO层的对象只能调用DAO层的对象！这是基本原则，要不我们还有分层干嘛？ 比如： 1）DAO层的UserMapper.findById()返回的User对象只包含：工号、姓名、年龄 2）Service层的UserMapper.findById()返回的User对象不仅包含：工号、姓名、年龄，还包含所属部门、拥有的角色列表…… 注意：这里Service层的User对象可不是DAO层的User对象！这就是你一直混淆的地方之一！
解决方案二：
和原来老项目比了下 老项目就是action,service,dao，每个业务都样这样老项目 java文件数量871个 1.9M大小 现在我建立的新项目java文件数量197个 551 KB
解决方案三：
大量程序生搬硬套分层思想，说下我目前项目的分层对于一般简单业务如只有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要什么事务，别给数据库增加压力希望对你有用
解决方案四：
如果是我的话，我会一个业务对象一个service，然后service调用多个DAO，DAO层应该只做数据的查询和存储，不涉及业务逻辑。 如果一个service里面的代码太多了的话，再根据业务再细分。 一个对象一个对象的存储数据不是条理很清晰吗？修改起来也只需要修改相对较小的SQL段。为了条理性，牺牲一点性能也是可以接受的。如果全部的逻辑都在一块，后续的修改只会让代码越来越难以维护。