关于ORM中只有XML没有映射实体的分析
開篇
????????? 上篇我們寫了關于《關于ORM中只有XML沒有映射實體的思考？期待大家的建議》這篇文章中描述了幾個可能的實現思路，但是總體來說，經過大家的建議和提醒，我發現了一些比較好的思
路，在這里特別感謝illumination?、金色海洋（jyk）?、賀臣?、Kevin Zou?等朋友們的支持和建議，我整理了下思路，并且經過金哥的指點得出一些新的思路。當然我這里結合這些思路進行整理，至
于上篇已經講述的內容，我本文就不闡述了，下面給出其他的幾個可行的思路的分析。
?????????? 由于目前項目中的一些特定的需求決定，還是接著上篇給出的需求，進行了部分的修改。整理如下
?????????? 1、修改了數據庫表，我們可以不修改界面調用的應用程序代碼。(所以我們這里之前的一個思路是使用XML而不是使用實體類）。
?????????? 2、修改了模型之后。能動態的反映到數據庫中(這個倒不是特別難實現的部分,而且目前已有很多成功的案例)。
?????????? 3、希望開發人員在使用這個動態映射的平臺時，能夠很方便的使用(使用習慣和開發模式上，易用性等方面)。
???????????????????? 4、維護性及可配置性方面的要求，并且能夠很方便的進行數據庫遷移(多數據的差異性的屏蔽,部署的環境差異性等)。
摘要
??????? 在前面幾位朋友的幫助下我們可以得到以下的幾類結論，下面我們來給出之前給出的3類解決方案之間的差異性和共性，并且針對目前的根據XML來完成映射時優缺點的對比，并且來分析，看看
有沒有其他的更好的途徑來完成這樣的映射呢？
??????? 本文將從以下的角度來分析，分析對于上面的幾個要求，來對比上篇給出的方案，并且展開來分析其他的可能的方案之間的差異性和共性，并且分析這些方案之間的優缺點。
??????? 1、基于XML和實體形式的ORM。
??????? 2、基于XML形式，沒有實體來完成映射的ORM。
??????? 3、基于XML并且結合字典或者我們自己包裝的單個實體類的形式。
??????? 4、沒有XML只有實體的形式，所有的映射都是通過實體來完成(通過特性或者是通過元數據)。
??????? 5、沒有XML也沒有實體，而是通過字典來完成所有的映射(數據庫中保存映射關系)。
??????? 6、EntityFramework + POCO Template的方案(illumination提出的解決方案)。
??????? 7、更多(請大家多多指點)
??????? 下面我們來逐個分析下吧。并且分析他們之間的差異性和優缺點。
本文大綱
???????? 1、開篇
???????? 2、摘要
???????? 3、本文大綱
???????? 4、ORM中的映射方案
???????? 5、本文總結
???????? 6、結論
ORM中的映射方案分析
?????????? 一、基于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的靈活配置，而且相對字典來說，使
用起來也還是會方便一些。并且通過自定義對象提供一些基礎的驗證等其他功能的集成等，都能夠豐富我們的操作，所以可能最理想的方案是這樣的，基于目前的項目情況所決定！
本文轉自何戈洲博客園博客，原文鏈接：http://www.cnblogs.com/hegezhou_hot/archive/2011/01/25/1944673.html，如需轉載請自行聯系原作者
總結
以上是生活随笔為你收集整理的关于ORM中只有XML没有映射实体的分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 汉语转拼音pinyin4j
- 下一篇： 2. Dubbo和Zookeeper的关