一、基于XML與實體

            

　　目前有很多的解決方案，都是這么來做的，比如Nhibernate中的配置，我們目前的項目中也是這樣的思路，不過這樣的思路，在項目的使用中有如下好處：

　　1、很方便開發人員使用，開發人員不用自己維護XML，只需要維護Entity即可，我們可以根據實體來生成XML，或者根據XML來生成實體。

　　2、使用XML可以很方便的屏蔽數據庫的差異性，因為一般情況下來說數據庫的差異對XML映射文件的影響不大。

　　3、使用實體類的形式，可以為開發人員可以很方便的使用，避免了一些在實體使用時的拼寫的錯誤，并且很方便調試時的跟蹤。

　　4、在生成SQL語句的時候，不要每次都反射實體類，只需要從XML讀取即可，提高效率。

　　但是也帶來了以下的問題。

　　1、如何將XML和實體類保持一致，一旦XML發生變更，或者目前我們遇到的最多的問題，就是表結構發生變化，那么就需要修改實體和XML，當然也可以提供代碼生成器，來反向根據數據庫表來生成映射的實體和XML。(必須全部重新生成，編譯，有些情況下我們不希望這樣)

　　2、還有就是XML太多，維護起來是個麻煩。

 二、基于XML沒有實體

                      

　　基于XML但是沒有實體的情況下，我們直接操作返回的datatable或者dataRow來完成對數據的訪問，這樣雖然可以減少實體的維護，也能處理數據庫表發生變化時，只要修改下XML文件即可，并且不需要重新修改程序也不需要編譯，但是也有一定的問題，我們下面來對比下優缺點：

　　優點

　　1、不要書寫實體類。

　　2、  不用維護XML與實體的差異性。

　　3、  不用處理一些數據轉換的操作。數據映射器等。

　　缺點

　　1、使用不方便，例如如果使用DataRow的使用，由于是弱類型，我們無法方便的使用。

　　2、不易于調試及驗證等。

　　3、 難以優化性能。    ;    

 三、基于XML與字典或自定義通用操作類

        ;           

　　上面給出可能的映射形式，當然還有其他的變種，前面給出的形式都是我們在上篇中給出的大致思路，本文不給出實現，只是給個思路，并且分析總結

　　我們來看看這種形式的優缺點：

　　優點：

　　1、實現了自定義通用實體來完成與所有XML進行映射的一種形式，這樣可以方便的即使數據庫表結構發生變化，或者模型發生變化時，我們都不需要改變我們的具體代碼。

　　2、因為我們這里的通用實體負責所有實體的數據的承載。所以我們對該通用對象進行開發即可，可以方便用戶使用。

　　缺點：

　　1、需要實現大量的底層通用對象功能。

　　2、開發人員使用的過程中，仍然無法像強類型對象一樣，可以通過屬性來訪問實體的數據信息，我們還是職能通過字典中的鍵值對的形式來訪問，無疑會帶來一定的難用性。

　　3、如果底層提供的功能不足或者對易用性方面的提供不足，會降低開發效率。

　　4、調試及跟蹤方面還是不太方便。

 四、基于實體映射

                     

　　如果我們不使用XML，而是之間采用實體映射的形式來完成ORM，那么無疑是最方便，也是效率最高的形式，因為不需要考慮一些轉換過程中出現的一些性能的損失等方便，至少可以說，這樣的形式，是性能損失相對來說很小的形式。前面的ORM系列中，我已經給出了部分實現，采用的是特性+反射的形式，來完成ORM，采用特性+反射的形式，可能性能上會有損失，但是如果采用的緩存得當，那么效率上不會差太多的。

　　那么我們來分析下，采用這樣的形式的優缺點吧

　　優點

　　1、一個實體類，對應數據庫中的一張表，那么有了實體類，使用起來很方便。

　　2、調試及跟蹤時，可以及時查看信息，很方便。

　　3、在調優及其他等方面可以很方便的進行操作。

　　4、避免了一些驗證方面的錯誤。

　　缺點

　　1、如果數據庫表結構或者實體發生變化都需要同步修改，否則會出現不可預料的錯誤。

　　2、如果修改了數據庫表，那么實體必須同步更新，并且還需要編譯。靈活性方面較差。

　　3、如果采用反射的形式，那么可能性能上是個瓶頸

 五、無(XML與實體)

　　通過一個通用的實體，來完成ORM映射，這時候，我們沒有為數據庫表中的每個表寫一個映射實體，我們通過在數據庫一個元數據表中，記錄這些與表進行映射的實體的相應信息，然后我們在通用實體中,去自動的填充通用實體對象，這樣就得到這樣的思路：

            

通過ORM，我們能夠得出如下的優缺點的對比

　　優點：

　　1、既不需要維護XML，也不需要維護實體。

　　2、無論是表發生變化，還是實體模型發生變化，我們都能夠做到數據庫的自動同步。比如通過觸發器來完成或者是存儲過程。

　　3、數據的一致性和性能相對來說比較高。

　　4、可維護較高。

　　缺點：

　　1、都放在數據庫中，使用的時候，還是要通過鍵值對的形式來讀取或者設置屬性。

　　2、對于關聯關系的對象，處理起來不是很方便。

　　3、緩存的策略很難制定。

　　4、數據庫差異性的移植等。

六、EntityFramework + POCO Template的方案

　　經過illumination的介紹，我也看了一下EntityFramework 的相關教程，具體的實現思路，我就不班門弄斧了，等具體研究完畢后，我會放出demo出來。

七、其他方案

　　希望大家能提出不同的方案和思路，希望大家指出批評。

總結

　　本文分析了幾類可能的ORM形式，當然市面上的一些集成的ORM框架，應該都是這樣大部分思路上都會或多或少的采用前面給出的幾類思路，當然如果您還有其他的思路，那么請你提出來!

結論

　　通過上面的幾個分析，如果我們必須采用基于XML的，并且要求能夠靈活的配置，那么可能還是使用通用映射對象來做會比較好，這樣不但能夠達到XML的靈活配置，而且相對字典來說，使

　　用起來也還是會方便一些。并且通過自定義對象提供一些基礎的驗證等其他功能的集成等，都能夠豐富我們的操作，所以可能最理想的方案是這樣的，基于目前的項目情況所決定！