本来打算在年前好好研究一下这个MyBatis 的ORM框架. 可是中间临时另有安排而不得已中断.目前开源的ORM框架已经太多了.其实在开源社区OSChina上可以看到已经成列各个语言/平台. 以前做过一段Java. 在.NET平台项目中叶也曾使用NHibernate和Spring.NET. 但大都是随着项目的完善提交而没有深入研究. 本篇作为MyBatis For .Net一个开篇.虽然使用过相关的ORM框架但对这个MyBatis了解甚少.. 也不知下面关于 MyBatis FOr .NEt这个主题上能写多少.
开源项目iBATIS一词来源于“internet”和“abatis”的组合，是一个由Clinton Begin在2001年发起的开放源代码项目。最初侧重于密码软件的开发，现在是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的JPetStore实例.
现在我们能从IBATIS项目中能分别看到衍生出来两个不同的版本.Net和Java. 当然这也是得益于开源社区的力量: 在Google of Code代码托管库中
MyBatis For JAva on Google Code
MyBatis For .NEt On Google Code
我大概Google一下相关的关于MyBatis中文资料相对比较少. 另外当你找到官方给你提供的相关Code Of Google上文档和代码实例你会发现Java和.Net版本之间的巨大差别. Java中Wiki文档提供相关源代码实例 已经相关文档说明.可惜的.NET上除了几句毫无意义的说明 基本上什么都没有了. 这对E文来说是一个”小挑战”.
相比我曾经用过的比较熟悉的NHibernate,MyBatis还是有自己突出的特点. 相信熟悉Nhibernate都应该知道, NHibernate对数据库结构提供了较为完整的一站式封装,代码自动生成，减少代码和sql的开发量，使开发人员摆脱开sql，ado.net和事务、缓存等底层. 而MyBatis相对Nhibernate 则体现 是在一种对ORM半自动化封装. 为何？ MyBATIS需要开发人员自己来写sql语句，这可以增加了程序的灵活性，在一定程度上可以作为ORM的一种补充.其实这样封装模式在实际项目需求下对ORM本身来说灵活性更强.
架构设计人员应该结合自己的项目的实际情况，来选择使用不同的策略。MyiBATIS和NHibernate都做了映射，但iBATIS是把实体类和sql语句之间建立了映射关系，这种策略可以允许开发人员自己来写合适的sql语句，而NHibernate在实体类和数据库之间建立了映射关系，sql对于开发人员是不可见的，对于那些数据量非常大的应用，无法去优化sql语句.
类似 现在项目团队中正在开发一个项目CodeExplorer.采用Nhibernate.做数据访问层映射. 当没过一天我们提交自己代码进行测试,项目DBA会立马过来说:"哪个谁谁谁？ 把一个PageFrom页面list数据检索修改一下 关联表太多. 性能参数太低." 你回应道:"这没法改! Nhibernate代码自动生成 SQL语句封装更是不可见的. 怎么改？ " 这种情景其实在Nhibernate架构项目中几位常见. 这也是完整一站式封装所不能适应项目需求的地方 就是灵活性. 这点给我映像最深的是在一些信息查询系统 NhiberNate表现在对于多表连接查询，复杂的sql实现如果本身满足不了需求有可能需要借助其他方案来解决性能问题. 另外值得注意 的是我们往往在追究性能问题过多关注数据体现上.其实问题真正原因是在数据库结构设计上是否合理也是有很大关系. 可见对数据库模式有较高的要求.NHibernate需要数据库有良好的设计和比较完善的约束. 才能体现出Nhiernate完整封装的优势. 而MyBaTis把SQL语句操作权从Nbiernate完整封装中重新交给了我们.
不知道还有人记得James Elliott的那句话，
As good object-oriented developers got tired of this repetitive work, their typical tendency towards enlightened laziness started to manifest itself in the creation of tools to help automate the process. When working with relational databases, the culmination of such efforts were object/relational mapping tools.