在《關于數據訪問模式（一）—— 數據訪問模式的重要性》 一文中，作者提到他們的團隊使用EJB時，性能極其的糟糕，然后不得不求助于存儲過程。但ORM產品的性能到底如何呢？我在網上搜索了一番，沒有找到相關的測試報告。
這幾天公司對ORM開發做評估，自然提到性能，這樣我們就自己做了一個LoadTest，具體的測試結果是不能說的，這是公司的東西，但我可以告訴你ORM（XPO）大概是DataSet（強類型DataSet）性能的1/3不到。
經理對這個測試結果甚微不滿，偶狂解釋不要拿ORM的弱勢跟表模式的比較啊，經理不予理睬。

于是我開始想解決方案。
問題：
1、我們知道ORM都是在運行時分析實體的Metadata信息，然后自動構建SQL語句，稍微好一點的ORM都會第一次獲取Metadata后就緩存一份，這樣還是可以快一些的。
2、但是數據Select出來之后，填充進去的時候還是要根據結構慢慢填充，不像DataSet就一個二維結構，填充簡單且賊快。
3、Metadata在ORM中都緩存了，但是Select、Insert、Update和Delete語句缺都是運行時構建的，而我們知道強類型的DataSet在設計時就幫你構建了，那性能當然沒有的說了。

解決方案：
辦法當然是向優秀者學習，我想象中我們的ORM實體和實體的Metadata還是老辦法，但是數據訪問層就不再運行時構建了，而是設計時自動創建代碼，就像我們強類型的DataSet一樣。
生成的代碼可能像這樣：

????internal?class?CustomerDataService?{
????????private?IDbCommand?cmdSelect_Customer;
????????private?IDbCommand?cmdInsert_Customer;
????????private?IDbCommand?cmdUpdate_Customer;
????????private?IDbCommand?cmdDelete_Customer;

????????private?IDbDataParameter?parSelect_CustomerId;

????????public?CustomerDataService()?{
????????????自動構建所有Command#region?自動構建所有Command

????????????#endregion
????????}

????????public?Customer?Read(int?id)?{
????????????parSelect_CustomerId.Value?=?id;
????????????IDataReader?read?=?cmdSelect_Customer.ExecuteReader();
????????????try?{
????????????????if?(read.Read())?{
????????????????????Customer?data?=?new?Customer();
????????????????????data.Oid?=?read.GetInt32(0);
????????????????????data.Name?=?read.GetString(1);
????????????????}
????????????????else?{
????????????????????throw?new?NotFindException(id);
????????????????}
????????????}
????????????finally?{
????????????????if?(read?!=?null?&&?!read.IsClosed)?{
????????????????????read.Close();
????????????????}
????????????}
????????}
????}

偶就不信這樣的代碼性能還會比他DataSet差。

面帶微笑，極度想象中

轉載于:https://www.cnblogs.com/tansm/archive/2005/07/22/197886.html

總結

以上是生活随笔為你收集整理的关于ORM的性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。