關於ORM中只有XML沒有映射實體的分析

開篇

          上篇咱們寫了關於《關於ORM中只有XML沒有映射實體的思考？期待你們的建議》這篇文章中描述了幾個可能的實現思路，可是整體來講，通過你們的建議和提醒，我發現了一些比較好的思

路，在這裏特別感謝illumination 、金色海洋（jyk） 、賀臣 、Kevin Zou 等朋友們的支持和建議，我整理了下思路，而且通過金哥的指點得出一些新的思路。固然我這裏結合這些思路進行整理，至

於上篇已經講述的內容，我本文就不闡述了，下面給出其餘的幾個可行的思路的分析。

           因爲目前項目中的一些特定的需求決定，仍是接着上篇給出的需求，進行了部分的修改。整理以下

           一、修改了數據庫表，咱們能夠不修改界面調用的應用程序代碼。(因此咱們這裏以前的一個思路是使用XML而不是使用實體類）。

           二、修改了模型以後。能動態的反映到數據庫中(這個倒不是特別難實現的部分,並且目前已有不少成功的案例)。

           三、但願開發人員在使用這個動態映射的平臺時，可以很方便的使用(使用習慣和開發模式上，易用性等方面)。

                     四、維護性及可配置性方面的要求，而且可以很方便的進行數據庫遷移(多數據的差別性的屏蔽,部署的環境差別性等)。

摘要

        在前面幾位朋友的幫助下咱們能夠獲得如下的幾類結論，下面咱們來給出以前給出的3類解決方案之間的差別性和共性，而且針對目前的根據XML來完成映射時優缺點的對比，而且來分析，看看

有沒有其餘的更好的途徑來完成這樣的映射呢？

        本文將從如下的角度來分析，分析對於上面的幾個要求，來對比上篇給出的方案，而且展開來分析其餘的可能的方案之間的差別性和共性，而且分析這些方案之間的優缺點。

        一、基於XML和實體形式的ORM。

        二、基於XML形式，沒有實體來完成映射的ORM。

        三、基於XML而且結合字典或者咱們本身包裝的單個實體類的形式。

        四、沒有XML只有實體的形式，全部的映射都是經過實體來完成(經過特性或者是經過元數據)。

        五、沒有XML也沒有實體，而是經過字典來完成全部的映射(數據庫中保存映射關係)。

        六、EntityFramework + POCO Template的方案(illumination提出的解決方案)。

        七、更多(請你們多多指點)

        下面咱們來逐個分析下吧。而且分析他們之間的差別性和優缺點。

本文大綱

         一、開篇

         二、摘要

         三、本文大綱

         四、ORM中的映射方案

         五、本文總結

         六、結論

ORM中的映射方案分析

           1、基於XML與實體

             

             目前有不少的解決方案，都是這麼來作的，好比Nhibernate中的配置，咱們目前的項目中也是這樣的思路，不過這樣的思路，在項目的使用中有以下好處：

             一、很方便開發人員使用，開發人員不用本身維護XML，只須要維護Entity便可，咱們能夠根據實體來生成XML，或者根據XML來生成實體。

             二、使用XML能夠很方便的屏蔽數據庫的差別性，由於通常狀況下來講數據庫的差別對XML映射文件的影響不大。

             三、使用實體類的形式，能夠爲開發人員能夠很方便的使用，避免了一些在實體使用時的拼寫的錯誤，而且很方便調試時的跟蹤。

             四、在生成SQL語句的時候，不要每次都反射實體類，只須要從XML讀取便可，提升效率。

             可是也帶來了如下的問題。

              一、如何將XML和實體類保持一致，一旦XML發生變動，或者目前咱們遇到的最多的問題，就是表結構發生變化，那麼就須要修改實體和XML，固然也能夠提供代碼生成器，來反向根據

              數據庫表來生成映射的實體和XML。(必須所有從新生成，編譯，有些狀況下咱們不但願這樣)

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

   2、基於XML沒有實體

                       

          基於XML可是沒有實體的狀況下，咱們直接操做返回的datatable或者dataRow來完成對數據的訪問，這樣雖然能夠減小實體的維護，也能處理數據庫表發生變化時，只要修改下XML文件即

可，而且不須要從新修改程序也不須要編譯，可是也有必定的問題，咱們下面來對比下優缺點：

          優勢

          一、  不要書寫實體類。

          二、  不用維護XML與實體的差別性。

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

          缺點

          一、使用不方便，例如若是使用DataRow的使用，因爲是弱類型，咱們沒法方便的使用。

          二、不易於調試及驗證等。

          三、 難以優化性能。        

           3、基於XML與字典或自定義通用操做類

                    

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

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

            優勢：

            一、實現了自定義通用實體來完成與全部XML進行映射的一種形式，這樣能夠方便的即便數據庫表結構發生變化，或者模型發生變化時，咱們都不須要改變咱們的具體代碼。

            二、由於咱們這裏的通用實體負責全部實體的數據的承載。因此咱們對該通用對象進行開發便可，能夠方便用戶使用。

            缺點：

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

            二、開發人員使用的過程當中，仍然沒法像強類型對象同樣，能夠經過屬性來訪問實體的數據信息，咱們仍是職能經過字典中的鍵值對的形式來訪問，無疑會帶來必定的難用性。

            三、若是底層提供的功能不足或者對易用性方面的提供不足，會下降開發效率。

            四、調試及跟蹤方面仍是不太方便。

           4、基於實體映射

                      

            若是咱們不使用XML，而是之間採用實體映射的形式來完成ORM，那麼無疑是最方便，也是效率最高的形式，由於不須要考慮一些轉換過程當中出現的一些性能的損失等方便，至少能夠說，這

樣的形式，是性能損失相對來講很小的形式。前面的ORM系列中，我已經給出了部分實現，採用的是特性+反射的形式，來完成ORM，採用特性+反射的形式，可能性能上會有損失，可是若是採用的

緩存得當，那麼效率上不會差太多的。

            那麼咱們來分析下，採用這樣的形式的優缺點吧

            優勢

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

            二、調試及跟蹤時，能夠及時查看信息，很方便。

            三、在調優及其餘等方面能夠很方便的進行操做。

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

            缺點

            一、若是數據庫表結構或者實體發生變化都須要同步修改，不然會出現不可預料的錯誤。

            二、若是修改了數據庫表，那麼實體必須同步更新，而且還須要編譯。靈活性方面較差。

            三、若是採用反射的形式，那麼可能性能上是個瓶頸

           5、無(XML與實體)

                       

             經過一個通用的實體，來完成ORM映射，這時候，咱們沒有爲數據庫表中的每一個表寫一個映射實體，咱們經過在數據庫一個元數據表中，記錄這些與表進行映射的實體的相應信息，而後咱們

在通用實體中,去自動的填充通用實體對象，這樣就獲得這樣的思路：

             

             經過ORM，咱們可以得出以下的優缺點的對比

             優勢：

             一、既不須要維護XML，也不須要維護實體。

             二、不管是表發生變化，仍是實體模型發生變化，咱們都可以作到數據庫的自動同步。好比經過觸發器來完成或者是存儲過程。

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

             四、可維護較高。

             缺點：

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

             二、對於關聯關係的對象，處理起來不是很方便。

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

             四、數據庫差別性的移植等。

           6、EntityFramework + POCO Template的方案

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

           7、其餘方案

             但願你們能提出不一樣的方案和思路，但願你們指出批評。

總結

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

             本文也是對比分析了每種形式的從我自身理解的優缺點，可能部分總結的不到位，或者說說說的不正確等，都請您指出，謝謝！

結論

             經過上面的幾個分析，若是咱們必須採用基於XML的，而且要求可以靈活的配置，那麼可能仍是使用通用映射對象來作會比較好，這樣不但可以達到XML的靈活配置，並且相對字典來講，使

用起來也仍是會方便一些。而且經過自定義對象提供一些基礎的驗證等其餘功能的集成等，都可以豐富咱們的操做，因此可能最理想的方案是這樣的，基於目前的項目狀況所決定！