【驳iBATIS那一大堆的不伦不类的JavaBean~~~~】iBatis中的DTO和FORM设计

    早有就这个想法，将自己在项目中用到的ibaits经验写出来，恰巧看到了这个标题，所以重新开了一个帖子，欢迎大家讨论一下。
    ibatis是一个轻量级的框架，他的优点在于Sql的自由化，这点我个人认为比hibernate好了很多，它比较灵活。但是问题来了，由于比较灵活，那么我们会面临一个问题，我们如何来操控它才是最优的。也许这个问题本身就是一个没有答案的问题，仁者见仁，智者见智，下面我只把自己的想法写下来，希望能帮助到希望得到帮助的人。
    对于web的三层结构，我们数据的传递流是这个样子的，Controller->service->dao->sqlmap->DB。那么我们该如何设计这个Bean呢，我认为这样是最佳的组合。Control（Form）->service（Dto）->dao.这样的好处在于，我们解耦了页面和数据库的对应关系。
    对于ibatis来说，单纯的增删改查，好像一般都是form和dto这两个bean没有什么区别，所以有些人可能会认为在control层和service层多出的form没有什么用处，但是业务复杂以后，你就会知道页面和数据库的解耦，是多么的重要。ok，今天的话题并不是讨论三层的bean设计，而是针对dto的设计。
    “iBATIS那一大堆的不伦不类的JavaBean“的作者可能还是一个在校的学生吧，这种看法，对于一个学生来讲，已经是很不错的。但是项目经验告诉我们，Dto的设计，并没有那么单纯，并不是一个简单的javaBean的问题，它涉及到了与数据库方面相关的内容。例如，一个新增操作，它设计到三个表的插入，这个dto你怎么设计呢，并且这个插入的动作并不是全表的插入操作，我们该怎么办。是针对所有需要插入的项，设计dto还是涉及到类似hibernate那样的orm映射，还是利用继承来设计呢？
    事实上，java的开发原则告诉我们，要将你实现的功能尽量拆分成元来进行，所谓的元，就是尽量的原子话，ok，遵循这个原则，我们需要将dto设计成orm的映射，即一个表对应一个dto。那么插入三个表，那就涉及到了三个表的dto数据来源问题，难道是我们需要将form中的每个字段都分别set到dto中吗，有重复的话，我们不是白做了很多的工作?好的，我们用sqlmap中的语句来解决它就可以了。
    所以，ibatis中的bean设计，绝对不是不伦不类的javabean，而是要符合你本身框架和数据库设计的综合bean的设计。
    以上只是个人看法，希望大家指正。

 

你应该看看原贴....


对于一些已知的项目,
会常常发现一些流程只关心很少的几个字段...
其它字段对于这些流程来说是噪音.

而且在现实中操作的人员
也会对这些已存在的属性规类(当然不这样子的话谁记的住那么多专业名词啊).
跟据以上两点拆分业务类作为
ibits的entityBean会减少很多不必要的麻烦.
扩展性就会完美体现出来(变更总是以专业概念为最小单位来改变.而不是属性或字段)

业务就是技术.技术中包括业务.

我是比较赞同用ibatis entity的。

主要还是因为灵活性问题～

客户的需求往往是像叠罗汉一样叠出来的～

所以灵活适应业务逻辑才是舒服的～～

ibatis的设计思想我想也在此了吧

另外，澄清下一个事实（因为也是刚毕业），毕业设计绝大多数同学的业务逻辑都很简单（我想自己不会故意去把问题搞复杂吧），所以会有一大堆无用的dao和entity.