关于ORM中只有XML没有映射实体的分析
開篇
????????? 上篇我們寫了關(guān)于《關(guān)于ORM中只有XML沒有映射實體的思考？期待大家的建議》這篇文章中描述了幾個可能的實現(xiàn)思路，但是總體來說，經(jīng)過大家的建議和提醒，我發(fā)現(xiàn)了一些比較好的思
路，在這里特別感謝illumination?、金色海洋（jyk）?、賀臣?、Kevin Zou?等朋友們的支持和建議，我整理了下思路，并且經(jīng)過金哥的指點得出一些新的思路。當(dāng)然我這里結(jié)合這些思路進(jìn)行整理，至
于上篇已經(jīng)講述的內(nèi)容，我本文就不闡述了，下面給出其他的幾個可行的思路的分析。
?????????? 由于目前項目中的一些特定的需求決定，還是接著上篇給出的需求，進(jìn)行了部分的修改。整理如下
?????????? 1、修改了數(shù)據(jù)庫表，我們可以不修改界面調(diào)用的應(yīng)用程序代碼。(所以我們這里之前的一個思路是使用XML而不是使用實體類）。
?????????? 2、修改了模型之后。能動態(tài)的反映到數(shù)據(jù)庫中(這個倒不是特別難實現(xiàn)的部分,而且目前已有很多成功的案例)。
?????????? 3、希望開發(fā)人員在使用這個動態(tài)映射的平臺時，能夠很方便的使用(使用習(xí)慣和開發(fā)模式上，易用性等方面)。
???????????????????? 4、維護(hù)性及可配置性方面的要求，并且能夠很方便的進(jìn)行數(shù)據(jù)庫遷移(多數(shù)據(jù)的差異性的屏蔽,部署的環(huán)境差異性等)。
摘要
??????? 在前面幾位朋友的幫助下我們可以得到以下的幾類結(jié)論，下面我們來給出之前給出的3類解決方案之間的差異性和共性，并且針對目前的根據(jù)XML來完成映射時優(yōu)缺點的對比，并且來分析，看看
有沒有其他的更好的途徑來完成這樣的映射呢？
??????? 本文將從以下的角度來分析，分析對于上面的幾個要求，來對比上篇給出的方案，并且展開來分析其他的可能的方案之間的差異性和共性，并且分析這些方案之間的優(yōu)缺點。
??????? 1、基于XML和實體形式的ORM。
??????? 2、基于XML形式，沒有實體來完成映射的ORM。
??????? 3、基于XML并且結(jié)合字典或者我們自己包裝的單個實體類的形式。
??????? 4、沒有XML只有實體的形式，所有的映射都是通過實體來完成(通過特性或者是通過元數(shù)據(jù))。
??????? 5、沒有XML也沒有實體，而是通過字典來完成所有的映射(數(shù)據(jù)庫中保存映射關(guān)系)。
??????? 6、EntityFramework + POCO Template的方案(illumination提出的解決方案)。
??????? 7、更多(請大家多多指點)
??????? 下面我們來逐個分析下吧。并且分析他們之間的差異性和優(yōu)缺點。
本文大綱
???????? 1、開篇
???????? 2、摘要
???????? 3、本文大綱
???????? 4、ORM中的映射方案
???????? 5、本文總結(jié)
???????? 6、結(jié)論
ORM中的映射方案分析
?????????? 一、基于XML與實體
?????????????
???????????? 目前有很多的解決方案，都是這么來做的，比如Nhibernate中的配置，我們目前的項目中也是這樣的思路，不過這樣的思路，在項目的使用中有如下好處：
???????????? 1、很方便開發(fā)人員使用，開發(fā)人員不用自己維護(hù)XML，只需要維護(hù)Entity即可，我們可以根據(jù)實體來生成XML，或者根據(jù)XML來生成實體。
???????????? 2、使用XML可以很方便的屏蔽數(shù)據(jù)庫的差異性，因為一般情況下來說數(shù)據(jù)庫的差異對XML映射文件的影響不大。
???????????? 3、使用實體類的形式，可以為開發(fā)人員可以很方便的使用，避免了一些在實體使用時的拼寫的錯誤，并且很方便調(diào)試時的跟蹤。
???????????? 4、在生成SQL語句的時候，不要每次都反射實體類，只需要從XML讀取即可，提高效率。
???????????? 但是也帶來了以下的問題。
????????????? 1、如何將XML和實體類保持一致，一旦XML發(fā)生變更，或者目前我們遇到的最多的問題，就是表結(jié)構(gòu)發(fā)生變化，那么就需要修改實體和XML，當(dāng)然也可以提供代碼生成器，來反向根據(jù)
????????????? 數(shù)據(jù)庫表來生成映射的實體和XML。(必須全部重新生成，編譯，有些情況下我們不希望這樣)
????????????? 2、還有就是XML太多，維護(hù)起來是個麻煩。
?? 二、基于XML沒有實體
???????????????????????
????????? 基于XML但是沒有實體的情況下，我們直接操作返回的datatable或者dataRow來完成對數(shù)據(jù)的訪問，這樣雖然可以減少實體的維護(hù)，也能處理數(shù)據(jù)庫表發(fā)生變化時，只要修改下XML文件即
可，并且不需要重新修改程序也不需要編譯，但是也有一定的問題，我們下面來對比下優(yōu)缺點：
????????? 優(yōu)點
????????? 1、? 不要書寫實體類。
????????? 2、? 不用維護(hù)XML與實體的差異性。
????????? 3、? 不用處理一些數(shù)據(jù)轉(zhuǎn)換的操作。數(shù)據(jù)映射器等。
????????? 缺點
????????? 1、使用不方便，例如如果使用DataRow的使用，由于是弱類型，我們無法方便的使用。
????????? 2、不易于調(diào)試及驗證等。
????????? 3、 難以優(yōu)化性能。????????
?????????? 三、基于XML與字典或自定義通用操作類
????????????????????
?????????? 上面給出可能的映射形式，當(dāng)然還有其他的變種，前面給出的形式都是我們在上篇中給出的大致思路，本文不給出實現(xiàn)，只是給個思路，并且分析總結(jié)
??????????? 我們來看看這種形式的優(yōu)缺點：
??????????? 優(yōu)點：
??????????? 1、實現(xiàn)了自定義通用實體來完成與所有XML進(jìn)行映射的一種形式，這樣可以方便的即使數(shù)據(jù)庫表結(jié)構(gòu)發(fā)生變化，或者模型發(fā)生變化時，我們都不需要改變我們的具體代碼。
??????????? 2、因為我們這里的通用實體負(fù)責(zé)所有實體的數(shù)據(jù)的承載。所以我們對該通用對象進(jìn)行開發(fā)即可，可以方便用戶使用。
??????????? 缺點：
??????????? 1、需要實現(xiàn)大量的底層通用對象功能。
??????????? 2、開發(fā)人員使用的過程中，仍然無法像強類型對象一樣，可以通過屬性來訪問實體的數(shù)據(jù)信息，我們還是職能通過字典中的鍵值對的形式來訪問，無疑會帶來一定的難用性。
??????????? 3、如果底層提供的功能不足或者對易用性方面的提供不足，會降低開發(fā)效率。
??????????? 4、調(diào)試及跟蹤方面還是不太方便。
?????????? 四、基于實體映射
??????????????????????
??????????? 如果我們不使用XML，而是之間采用實體映射的形式來完成ORM，那么無疑是最方便，也是效率最高的形式，因為不需要考慮一些轉(zhuǎn)換過程中出現(xiàn)的一些性能的損失等方便，至少可以說，這
樣的形式，是性能損失相對來說很小的形式。前面的ORM系列中，我已經(jīng)給出了部分實現(xiàn)，采用的是特性+反射的形式，來完成ORM，采用特性+反射的形式，可能性能上會有損失，但是如果采用的
緩存得當(dāng)，那么效率上不會差太多的。
??????????? 那么我們來分析下，采用這樣的形式的優(yōu)缺點吧
??????????? 優(yōu)點
??????????? 1、一個實體類，對應(yīng)數(shù)據(jù)庫中的一張表，那么有了實體類，使用起來很方便。
??????????? 2、調(diào)試及跟蹤時，可以及時查看信息，很方便。
??????????? 3、在調(diào)優(yōu)及其他等方面可以很方便的進(jìn)行操作。
??????????? 4、避免了一些驗證方面的錯誤。
??????????? 缺點
??????????? 1、如果數(shù)據(jù)庫表結(jié)構(gòu)或者實體發(fā)生變化都需要同步修改，否則會出現(xiàn)不可預(yù)料的錯誤。
??????????? 2、如果修改了數(shù)據(jù)庫表，那么實體必須同步更新，并且還需要編譯。靈活性方面較差。
??????????? 3、如果采用反射的形式，那么可能性能上是個瓶頸
?????????? 五、無(XML與實體)
???????????????????????
???????????? 通過一個通用的實體，來完成ORM映射，這時候，我們沒有為數(shù)據(jù)庫表中的每個表寫一個映射實體，我們通過在數(shù)據(jù)庫一個元數(shù)據(jù)表中，記錄這些與表進(jìn)行映射的實體的相應(yīng)信息，然后我們
在通用實體中,去自動的填充通用實體對象，這樣就得到這樣的思路：
?????????????
???????????? 通過ORM，我們能夠得出如下的優(yōu)缺點的對比
???????????? 優(yōu)點：
???????????? 1、既不需要維護(hù)XML，也不需要維護(hù)實體。
???????????? 2、無論是表發(fā)生變化，還是實體模型發(fā)生變化，我們都能夠做到數(shù)據(jù)庫的自動同步。比如通過觸發(fā)器來完成或者是存儲過程。
???????????? 3、數(shù)據(jù)的一致性和性能相對來說比較高。
???????????? 4、可維護(hù)較高。
???????????? 缺點：
???????????? 1、都放在數(shù)據(jù)庫中，使用的時候，還是要通過鍵值對的形式來讀取或者設(shè)置屬性。
???????????? 2、對于關(guān)聯(lián)關(guān)系的對象，處理起來不是很方便。
???????????? 3、緩存的策略很難制定。
???????????? 4、數(shù)據(jù)庫差異性的移植等。
?????????? 六、EntityFramework + POCO Template的方案
?????????????????????? 經(jīng)過illumination的介紹，我也看了一下EntityFramework 的相關(guān)教程，具體的實現(xiàn)思路，我就不班門弄斧了，等具體研究完畢后，我會放出demo出來。
?????????? 七、其他方案
???????????? 希望大家能提出不同的方案和思路，希望大家指出批評。
總結(jié)
???????????? 本文分析了幾類可能的ORM形式，當(dāng)然市面上的一些集成的ORM框架，應(yīng)該都是這樣大部分思路上都會或多或少的采用前面給出的幾類思路，當(dāng)然如果您還有其他的思路，那么請你提出來
???????????? 本文也是對比分析了每種形式的從我自身理解的優(yōu)缺點，可能部分總結(jié)的不到位，或者說說說的不正確等，都請您指出，謝謝！
結(jié)論
???????????? 通過上面的幾個分析，如果我們必須采用基于XML的，并且要求能夠靈活的配置，那么可能還是使用通用映射對象來做會比較好，這樣不但能夠達(dá)到XML的靈活配置，而且相對字典來說，使
用起來也還是會方便一些。并且通過自定義對象提供一些基礎(chǔ)的驗證等其他功能的集成等，都能夠豐富我們的操作，所以可能最理想的方案是這樣的，基于目前的項目情況所決定！
本文轉(zhuǎn)自何戈洲博客園博客，原文鏈接：http://www.cnblogs.com/hegezhou_hot/archive/2011/01/25/1944673.html，如需轉(zhuǎn)載請自行聯(lián)系原作者
總結(jié)
以上是生活随笔為你收集整理的关于ORM中只有XML没有映射实体的分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 汉语转拼音pinyin4j
- 下一篇： 2. Dubbo和Zookeeper的关