iBATIS那一大堆的不伦不类的JavaBean~~~~

最近做毕业设计的时候，在持久层的框架用了iBATIS，而没有用Hibernate，但是写了几个模块之后越来越不爽。在做像高级查询的这种需要连接多张表的操作的时候，由于iBATIS并不是真正意义上的ORM，所以不得不为每一种查询的输入参数和输出参数量身定做各种不伦不类的JavaBean，真不知道把他们搁置在哪个包里面，新建一个bizModel包与持久层的model包并列？而写死了的model层跟数据库表对应的对象看起来很鸡肋，因为事实上，就查询而言，进行单表操作很少。大家是什么看法？

看了回帖后的补充，拜托某些只知道骂人的前辈看明白我的意思再回帖：

可能很多人都没理解我的意思，我就问一句好了，在取数据的时候，是该采用增加DTO映射结果呢，还是用Entity？采用DTO的好处是，查询数据对应于一个类的属性，映射简单，取数据也简单，但是会导致类的数量的膨胀。用Entity的好处和坏处正好相反。类的数量不会随着业务的变化而增多，但是映射会变的复杂，取数据需要对应于多个bean，性能也会打折扣。

简直是扯淡

那您怎么就没有一点自己的看法呢？遗憾~~~~~~

并不是因为你用了ibatis之后才出现这些你所谓的不伦不类的JavaBean,这些本来应该是你的Domain,而只是用ibatis来持久化,只能说明你主次不分,完全没有概念

那您不觉得，这些所谓的Domain会随着你的业务的增多而增多吗？不能像Hibernate那样，基本上与数据库对应的PO就搞定了。至少，也应该找一个好点的方法去减少这些多而难以维护的bean。看了以前的帖子，有人说是用map，我觉得可读性和维护性会很差。

crud还是用jdbc吧
做个毕业设计没必要搞那么复杂
你够强就自己写个小OR映射框架咯
其实都不难，10几天的事情。

倒,你的Domain设计与ibatis,hibernate无关,或者说关系不是很大,只是最终的持久化实现不一样而已,一个简单的例子用户这个对象,无论你是用hibernate还是ibatis都是存在的,如果不是这样说明你做的方式有问题或者你的代码结构有问题

换句话说,即使你用的是jdbc,最后的只是service的实现不一样而已,但是整个系统的结构还是那样

PO不就是你的Domain吗,你把它用ibatis持久化不就可以了?

您可能误解我的意思了，我是意思是：实体Bean是写死的，跟数据库表对应的。而业务Bean是千变万化的。我想问有没有方法，来减少业务bean的数量，同时，对于iBATIS这个本质上非ORM框架而言，实体bean是否要像Hibernate那样一一跟数据库表对应写死，还是只需要设计业务bean就行了。
您刚才说的持久层跟业务层无关，理论谁都知道，我想最大的好处在于后面的维护吧，而在设计之初，是不是应该针对选择的框架不同而选择更好的设计呢？

Hibernate是完全面向对象来维护关系的，而iBATIS却不是。对于需要多表的操作，持久化怎么一样了？