MyBatis For .NET學習筆記:開篇

<a target="_blank" href="http://blog.51cto.com/attachment/201201/111143539.png"></a>

現在我們能從IBATIS項目中能分别看到衍生出來兩個不同的版本.Net和Java. 當然這也是得益于開源社群的力量: 在Google of Code代碼托管庫中

<a target="_blank" href="http://www.mybatis.org/index.html">MyBatis 官網: MyBatis Web Site</a>

<a target="_blank" href="http://code.google.com/p/mybatis/">MyBatis For JAva on Google Code</a>

<a target="_blank" href="http://code.google.com/p/mybatis/">MyBatis For .NEt On Google Code</a>

我大概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.

本文轉自chenkaiunion 51CTO部落格，原文連結:http://blog.51cto.com/chenkai/763806