随笔1

看了论坛上高手和新手对Ibatis的讨论，抱着学习的态度，写写自己的一点理解和感想。
首先，应该鼓励不懂的人谈自己的看法，暴露自己知识的缺乏，这没什么不好，大家都需要进步。只有那些虽然无知却还不敢承认，或者怕别人知道自己无知的人才最可怕。每个人都可以坦诚自己的观点，但是不应以人身攻击为手段。
然后，作为高手或者自认为对问题有比较透彻了解的人应该回复有建设性的文字，而不该以嗤之以鼻来应对。要知道并非所有的人都那么聪明。再，或者不要回复，一笑而过也好，总强过打嘴仗，脱离问题本身。

我的理解也是浅显的，自认为没有学得那么好。我理解这个问题不单纯是要讨论Ibatis怎么使用的问题。还涉及到数据模型和整体架构的问题。
（1）先从数据模型的层面来说。
其一、我理解尽量避免出现结构很大的表，拥有N多字段，甚至里面包括了大对象字段BLOB或者CLOB。特别是这个表将来会成为拥有N多数据，甚至海量数据的表。对于这样的表进行查询是比较费时的。如果，业务上要求有这样一个entity，那最好对其进行拆分。拆分的原则我理解将基础的信息拆分出来，特别是要作为查询条件的部分。特别是要将大对象和占用空间比较大的字段拆分到其他子表中。理想情况下，我们当然希望只将作为查询条件的字段拆分到主表中。这样能够使得表足够小。但是，业务可能会变化，查询的条件可能会变化，调整也可能会出现。所以在主表中的字段除了查询条件还可以多些，只要认为适当就可以了。
其二、对于主从表的结构尽量能做到层次不要太多，自己认为2层足够了，如果超过3层就显得很多了。操作起来就会非常麻烦和复杂。这里也包括上面大表拆分的情况。
其三、对于主从表的个数，一个主表对应多个从表。这里从表的数量也最好能够得到控制。因为，如果我们采用单表查询的方式，先查主表，再分别查从表，其速度就会跟从表的数量有关。当然对于一个特定的业务查询，也并非要查询所有的从表。

（2）从页面显示的层面来说

其一、通常应用会分为列表页面或者叫查询页面和详细页面。对于列表页面应该显示业务主数据，通常是主表的内容。注意，我是说通常。页面设计应该秉承这样的原则。进入详细页面以后再显示相关子表的内容。这样的设计会和（1）中的一的原则相吻合。

（3）从Ibatis的层面说
其一、查询条件可能涉及主表、从表多个表。使用Ibatis我建议传入参数还是使用Map。这样避免新建JavaBean，扩展也很灵活。比如新增查询项。

其二、对于结果集，Ibatis中使用ResultMap来映射JavaBean与数据库表字段的关系。这其实跟Hibernate没太大区别。如果满足（1）中一和（2）中一的设计原则。其ResultMap可以只是针对一个数据库表，或者说返回的结果集类型只是一个已经存在的PO，它与数据库表一一对应的。

其三、有人担心如二中处理会出现N+1或者说M*N+1的问题。但是该问题可大可小，通常我认为问题不大，除非特殊情况下，比如需要查询的子表很多。因为，对于列表页面，通常是要分页的，其中对于主表的查询返回结果集在10个左右。当然，这确实增加了查询次数，但是只要系统能够响应比较快，问题可以不用考虑。特别是查询如果只返回主表结果集的时候，就更不会出现N+1的问题。

其四、最糟糕的是，要求查询结果集包括主表和多个从表的记录一起，而且又是多个超大的表进行关联查询。对于这样的问题的处理本身就是个棘手的问题。涉及到SQL的性能调优。Ibatis本身也支持定义嵌套的ResultMap。当然也可以定义一个新的ResultMap对应一个结果集建立一个JavaBean。而且结果集还可以定义为Map。但是，这样的查询应该在设计中尽量减少。

其实直接处理复杂SQL是Ibatis的特点。所以特别是复杂的查询，使用Ibatis才更合适。即使为此，新建立一些JavaBean也是很值得的。当然，在速度允许的情况下，也没有必要一味的要躲避所谓的N+1，在一般情况下的N+1也是可以接受的。如果速度实在慢，再考虑返回多个表的结果集在一起的情况。