論資料庫通路元件的選擇--火地晉大作讀後感前言選擇原則結論

這裡要讨論一下我們用一個什麼樣的政策來選擇資料庫通路元件。通常有如下幾種情況來選擇：

1. 基于過去的經驗

   比如過去用過某某ORM，在将來的項目中繼續用的話經驗和熟練度就會比較高。這是建立在對該ORM的信任基礎之上的。

2. 别人介紹或者在網上自己發現的，然後再試用也不錯

  這種情況也挺普遍的。業界同僚介紹某某ORM不錯，或者在網絡上發現一個資料庫通路架構不錯。再經過試用，發現還不錯。就在項目中采用。

  上述這兩種情況中都有試用或者使用的經曆，在試用和使用過程中我們考察什麼呢， 主要是這些：

1. 便利性

  調用是否友善。是否易用。團隊是否容易采用。

2. 性能

  該ORM或者資料庫通路架構是否提供足夠好的資料庫通路性能。

3. 多線程情況下有否限制

  多線程情況是程式中一個很普遍的現象，該ORM或者架構是否在多線程情況下有限制。這是一個必須通過的考察項目，如果不能通過的話，最好不要選用該ORM或者架構。

4. 事務處理是否足夠完備

  單個資料庫的事務處理是否支援，分布式資料庫事務是否支援。支援的資料庫事務協調器是哪些。分布式資料庫事務不是必須的。不需要分布式事務的情況下，某些ORM或者架構不支援分布式事務是允許的。但是單個資料庫的事務處理是必須要支援的。不然該ORM或者架構是不能選擇的。

5. 安全性

  對于防止SQL 注入有沒有提供措施。這是必須的。

6. 可擴充性

  當ORM或者架構現有功能不足以滿足項目要求，比如ORM産生的SQL不夠優化，怎麼辦？有沒有擴充的方法來解決。這個不是必須的，但是有的話更好。

7. 可維護性

 可維護性指的是該ORM或者架構有沒有人持續提供更新，維護；如果一個架構用的人手少，然後維護它的人很久都不出維護版本，我們估計就很難選擇這樣的架構了。然後就是我們本身可否看到其源碼，了解其本身是如何運作的。我們進而可以寫出更配合的代碼來。如果看不到源嗎，這方面就會減分。

  我們可以選擇的ORM或者架構很多。每個ORM或者架構在這幾個方面的得分是不一樣的。我們其實沒有那麼多時間去使用那麼多的ORM或者架構。隻有從知道的幾個當中選一個。在所有ORM之外，我們其實還有一個ado.net的選擇， ado.net的方式，其性能可以做到最好，但是其便利性不如那些ORM，還有可維護性也不是足夠好。所有這些選項都經過我們的考察，才能選中合适項目的資料庫通路架構或者技術。

  這裡的建議是我們還是盡量用那些使用面比較廣的，開源的，經常更新的ORM或者架構。像那些不開源的，更新沒保障的，品質沒保障的ORM或者架構，最好還是别用。當然了，你要用的話，後果自付。隻有在極端要求性能的情況下或者是當你有辦法提高ado.net的便利性和可維護性的情況下，才去選擇ado.net。