(本文已過時,請到: http://www.cnblogs.com/humble/p/3320804.html
1.高性能是Moon.ORM優勢之一,也是我架構它的主要目的之一,我已經將它的性能提升到了極致.如以前我說的那樣,是為了彌補項目中遇到的性能問題而設計.可以說對於整個框架數據處理上采用了純的ADO.NET進行自動編譯的同時結合了EMIT達到快速生成實體的目的.
我不得不承認linq和lambda語句帶來的優雅,但同時我們需要承認linq的局限性.或許有人說可以通過手段進行一些彌補,如有人以提高 linq性能來寫文章一樣,但我們需要承認兩個事實,每次對linq的系統識別后才能進行優化,也就是說,linq的天性決定有性能損失.再次linq不 是銀彈,因為負責的場合linq幾乎是做不到的,何況linq生成的sql不一定是你真正要的.(注意:我不是敵對linq,而是說實話,正如曾說:實際開發中沒有銀彈,只有平衡點,適合需求能解決實際情況的架構那就夠了)而且我也沒有必要再去寫一個框架,做一個類似Nhibernate,或者實體框架的東西.做東西我一直認為需要做一個能有自我的特色和優勢.
2.易用性強大,我想用過Moon.ORM的應該可以知道這點.配置簡單,智能感知,代碼生成器的輔助,會sql就可會用Moon.
3.多數據庫多數據源支持.在同一個項目中我們需要處理這種情況時,Moon.ORM是你最好的選擇.如你系統默認為MSSQL,現在要同時使用 MYSQL,你只需要實例化一個引擎就可以.DBFactory.GetEntity<Person> (pjy_AdminRoleTable.RoleID.BiggerThan(0),new MYSQL("連接字符串"));當然你可以把引擎做成全局的.
4.語法糖功能.個人使用的結果是大概能滿足我實際需求的70%以上的功能.
5..NET 2.0原生支持,這個就不用說了.
6.數據庫轉變問題,如果你發現你有一天你的數據庫需要從mysql轉變到mssql,你只需要轉變你的配置文件即可.(當然sql語法差異的問題,你需要自己注意了,如果你在用原生的sql進行操作時).
歷經了兩個公司的發展,穩定性可得而知.曾在合富網絡的主營產品中應用於一年的開發框架中.及潘家園文化傳媒主營平台新系統.且得到Moon愛好者在實際項目中的肯定.
3.使用問題
此框架對於任何人群及個人可以免費使用.
有人曾說'都沒源代碼,所以我不能用'.我不能自比微軟,但我們可以換一個位置想想:知道.net framework 3.5 sp1中的bug嗎?微軟的庫中也會有bug信嗎?Moon.ORM標准版,一律免費使用(包括API文檔等)和群技術支持.對於企業用戶我會提供專門的服務和技術支持以及更加美觀強大易用的企業版Moon.orm代碼生成器工具及技術培訓資料.
4.常見問題
1.代碼生成器在sqlserver2000暫未提供技術支持.
2.沒有主鍵的表代碼生成器會報錯
3.系統中非.NET有的字段類型不支持
5.同類產品對比
1.對於實體框架,實體框架的性能問題,我不知道現今如何,但4.0的測試中足以見到http://www.cnblogs.com/humble/archive/2011/05/19/2051053.html
這也是我前一公司項目延期的一個原因.當時Moon.ORM還是1.0的版本以Qin.Data命名.
我不是要說實體框架怎樣,至少那時的它讓我們陷入沼澤,性能有時候是項目的關鍵.
2.對於Nhibernate,它的確不錯,但不可置疑顯得很復雜,或許簡單易用可以作為Moon與它的對比吧.
3.對於iBATIS用過的人就知道,一堆的配置,每當要做查詢你需要從寫一堆配置.
4.其他類型的我就不想多說了,因為實際項目中沒有銀彈,適合環境適合自己的那才是最好的.您若不滿意請飄過.
5.我不得不說沒有一個ORM可以解決正真復雜的sql問題,nhibernate和ef同樣也是如此,這也是Moon所面臨的.
6.使用說明
7.最新版下載地址.
1.對於數據庫的設計,每一個表必須要有主鍵;
2.由業務決定邏輯的主鍵設計方案是錯誤的,所以主鍵是不能被業務牽制的,因為業務是變動的.Moon.ORM需建立獨立於業務
之外的.所以主鍵的設計MOON選擇的是guid或者自增的情況(建議用自增的方式).
9.配置問題
1.下載代碼生成器(上面,最新版本下載)
2.修改代碼生成器的配置文件.如下圖.(如果是mysql見 6.使用說明)
(可以把這段代碼文件.cs復制到項目中,也可引用編譯文件.dll)
4.實際項目中引入Moon.Orm和上面生成的.cs或.dll
QQ群技術交流: