于上篇已經講述的内容，我本文就不闡述了，下面給出其他的幾個可行的思路的分析。 由于目前項目中的一些特定的需求決定，還是接着上篇給出的需求，進行了部分的修改。整理如下 1、修改了資料庫表，我們可以不修改界面調用的應用程式代碼。(是以我們這裡之前的一個思路是使用XML而不是使用實體類）。 2、修改了模型之後。能動态的反映到資料庫中(這個倒不是特别難實作的部分,而且目前已有很多成功的案例)。 3、希望開發人員在使用這個動态映射的平台時，能夠很友善的使用(使用習慣和開發模式上，易用性等方面)。
4、維護性及可配置性方面的要求，并且能夠很友善的進行資料庫遷移(多資料的差異性的屏蔽,部署的環境差異性等)。
在前面幾位朋友的幫助下我們可以得到以下的幾類結論，下面我們來給出之前給出的3類解決方案之間的差異性和共性，并且針對目前的根據XML來完成映射時優缺點的對比，并且來分析，看看 有沒有其他的更好的途徑來完成這樣的映射呢？ 本文将從以下的角度來分析，分析對于上面的幾個要求，來對比上篇給出的方案，并且展開來分析其他的可能的方案之間的差異性和共性，并且分析這些方案之間的優缺點。 1、基于XML和實體形式的ORM。 2、基于XML形式，沒有實體來完成映射的ORM。 3、基于XML并且結合字典或者我們自己包裝的單個實體類的形式。 4、沒有XML隻有實體的形式，所有的映射都是通過實體來完成(通過特性或者是通過中繼資料)。 5、沒有XML也沒有實體，而是通過字典來完成所有的映射(資料庫中儲存映射關系)。 7、更多(請大家多多指點) 下面我們來逐個分析下吧。并且分析他們之間的差異性和優缺點。
1、開篇 2、摘要 3、本文大綱 4、ORM中的映射方案 5、本文總結 6、結論
目前有很多的解決方案，都是這麼來做的，比如Nhibernate中的配置，我們目前的項目中也是這樣的思路，不過這樣的思路，在項目的使用中有如下好處： 1、很友善開發人員使用，開發人員不用自己維護XML，隻需要維護Entity即可，我們可以根據實體來生成XML，或者根據XML來生成實體。 2、使用XML可以很友善的屏蔽資料庫的差異性，因為一般情況下來說資料庫的差異對XML映射檔案的影響不大。 3、使用實體類的形式，可以為開發人員可以很友善的使用，避免了一些在實體使用時的拼寫的錯誤，并且很友善調試時的跟蹤。 4、在生成SQL語句的時候，不要每次都反射實體類，隻需要從XML讀取即可，提高效率。 但是也帶來了以下的問題。 1、如何将XML和實體類保持一緻，一旦XML發生變更，或者目前我們遇到的最多的問題，就是表結構發生變化，那麼就需要修改實體和XML，當然也可以提供代碼生成器，來反向根據 資料庫表來生成映射的實體和XML。(必須全部重新生成，編譯，有些情況下我們不希望這樣) 2、還有就是XML太多，維護起來是個麻煩。
關于ORM中隻有XML沒有映射實體的分析開篇摘要本文大綱ORM中的映射方案分析總結結論
基于XML但是沒有實體的情況下，我們直接操作傳回的datatable或者dataRow來完成對資料的通路，這樣雖然可以減少實體的維護，也能處理資料庫表發生變化時，隻要修改下XML檔案即 可，并且不需要重新修改程式也不需要編譯，但是也有一定的問題，我們下面來對比下優缺點： 優點 1、 不要書寫實體類。 2、 不用維護XML與實體的差異性。 3、 不用處理一些資料轉換的操作。資料映射器等。 缺點 1、使用不友善，例如如果使用DataRow的使用，由于是弱類型，我們無法友善的使用。 2、不易于調試及驗證等。 3、 難以優化性能。
上面給出可能的映射形式，當然還有其他的變種，前面給出的形式都是我們在上篇中給出的大緻思路，本文不給出實作，隻是給個思路，并且分析總結 我們來看看這種形式的優缺點： 優點： 1、實作了自定義通用實體來完成與所有XML進行映射的一種形式，這樣可以友善的即使資料庫表結構發生變化，或者模型發生變化時，我們都不需要改變我們的具體代碼。 2、因為我們這裡的通用實體負責所有實體的資料的承載。是以我們對該通用對象進行開發即可，可以友善使用者使用。 缺點： 1、需要實作大量的底層通用對象功能。 2、開發人員使用的過程中，仍然無法像強類型對象一樣，可以通過屬性來通路實體的資料資訊，我們還是職能通過字典中的鍵值對的形式來通路，無疑會帶來一定的難用性。 3、如果底層提供的功能不足或者對易用性方面的提供不足，會降低開發效率。 4、調試及跟蹤方面還是不太友善。
如果我們不使用XML，而是之間采用實體映射的形式來完成ORM，那麼無疑是最友善，也是效率最高的形式，因為不需要考慮一些轉換過程中出現的一些性能的損失等友善，至少可以說，這 樣的形式，是性能損失相對來說很小的形式。前面的ORM系列中，我已經給出了部分實作，采用的是特性+反射的形式，來完成ORM，采用特性+反射的形式，可能性能上會有損失，但是如果采用的 緩存得當，那麼效率上不會差太多的。 那麼我們來分析下，采用這樣的形式的優缺點吧 優點 1、一個實體類，對應資料庫中的一張表，那麼有了實體類，使用起來很友善。 2、調試及跟蹤時，可以及時檢視資訊，很友善。 3、在調優及其他等方面可以很友善的進行操作。 4、避免了一些驗證方面的錯誤。 缺點 1、如果資料庫表結構或者實體發生變化都需要同步修改，否則會出現不可預料的錯誤。 2、如果修改了資料庫表，那麼實體必須同步更新，并且還需要編譯。靈活性方面較差。 3、如果采用反射的形式，那麼可能性能上是個瓶頸
通過一個通用的實體，來完成ORM映射，這時候，我們沒有為資料庫表中的每個表寫一個映射實體，我們通過在資料庫一個中繼資料表中，記錄這些與表進行映射的實體的相應資訊，然後我們 在通用實體中,去自動的填充通用實體對象，這樣就得到這樣的思路：通過ORM，我們能夠得出如下的優缺點的對比 優點： 1、既不需要維護XML，也不需要維護實體。 2、無論是表發生變化，還是實體模型發生變化，我們都能夠做到資料庫的自動同步。比如通過觸發器來完成或者是存儲過程。 3、資料的一緻性和性能相對來說比較高。 4、可維護較高。 缺點： 1、都放在資料庫中，使用的時候，還是要通過鍵值對的形式來讀取或者設定屬性。 2、對于關聯關系的對象，處理起來不是很友善。 3、緩存的政策很難制定。 4、資料庫差異性的移植等。關于ORM中隻有XML沒有映射實體的分析開篇摘要本文大綱ORM中的映射方案分析總結結論
希望大家能提出不同的方案和思路，希望大家指出批評。
本文分析了幾類可能的ORM形式，當然市面上的一些內建的ORM架構，應該都是這樣大部分思路上都會或多或少的采用前面給出的幾類思路，當然如果您還有其他的思路，那麼請你提出來 本文也是對比分析了每種形式的從我自身了解的優缺點，可能部分總結的不到位，或者說說說的不正确等，都請您指出，謝謝！
通過上面的幾個分析，如果我們必須采用基于XML的，并且要求能夠靈活的配置，那麼可能還是使用通用映射對象來做會比較好，這樣不但能夠達到XML的靈活配置，而且相對字典來說，使 用起來也還是會友善一些。并且通過自定義對象提供一些基礎的驗證等其他功能的內建等，都能夠豐富我們的操作，是以可能最理想的方案是這樣的，基于目前的項目情況所決定！ 本文轉自何戈洲部落格園部落格，原文連結：http://www.cnblogs.com/hegezhou_hot/archive/2011/01/25/1944673.html，如需轉載請自行聯系原作者