ORM優勢和缺點

轉自：http://blog.csdn.net/sgear/article/details/7408251

1．什麼是ORM?

ORM，即Object-Relational Mapping（對象關係映射），它的做用是在關係型數據庫和業務實體對象之間做一個映射，這樣，咱們在具體的操做業務對象的時候，就不須要再去和複雜的SQL語句打交道，只需簡單的操做對象的屬性和方法。

2．Snake.Net中ORM的特色與概述：

         Snake.Net框架是基於.Net的應用而設計的，它和其餘一些移植於Java的ORM應用構架不一樣，是徹底根據.Net的特色設計和開發。

Snake.Net框架使用一個完整的DataSet構架(見圖2-1-1)，用以描述一個應用項目所涉及的數據結構（包括可描述性的表結構、關鍵字、外部關鍵字以及表與表之間的關係等）。並使用特定的方法，將DataSet構架內所描述的數據表、數據列、關鍵字、表之間的關聯關係與具體的業務實體對象進行映射，並實現業務實體對象的數據訪問。  

3．數據庫聯接的設置：

  

ORM系統是與數據庫進行交互操做，和數據庫的鏈接就成爲最首要的話題。Snake.Net框架支持業務實體對一個或多個不一樣類型的數據庫的訪問支持，在框架內可使用兩種方法設置數據庫鏈接：使用配置文件和運行時設置。

Snake.Net容許在一個系統中能夠同時使用多個數據庫配置。同時提供了對不一樣種類的數據庫具備廣乏的支持，幾乎可使用當前全部主流的數據庫產品。

優點：ORM自其概念被提出，就獲得了無數的響應，花樣繁多的應用框架更是目不暇接。可見，他是有其獨到的優點的。那麼他的優點有哪些那：

首先，ORM最大的優點。


        隱藏了數據訪問細節，「封閉」的通用數據庫交互，ORM的核心。他使得咱們的通用數據庫交互變得簡單易行，而且徹底不用考慮該死的SQL語句。快速開發，由此而來。


第二：ORM使咱們構造固化數據結構變得簡單易行。


         在ORM年表的史前時代，咱們須要將咱們的對象模型轉化爲一條一條的SQL語句，經過直連或是DB helper在關係數據庫構造咱們的數據庫體系。而如今，基本上全部的ORM框架都提供了經過對象模型構造關係數據庫結構的功能。這，至關不錯。

缺點：


第一：


        無可避免的，自動化意味着映射和關聯管理，代價是犧牲性能（早期，這是全部不喜歡ORM人的共同點）。如今的各類ORM框架都在嘗試使用各類方法來減輕這塊（LazyLoad，Cache），效果仍是很顯著的。


第二：


         面向對象的查詢語言(X-QL)做爲一種數據庫與對象之間的過渡,雖然隱藏了數據層面的業務抽象,但並不能徹底的屏蔽掉數據庫層的設計,而且無疑將增長學習成本.

第三：


         對於複雜查詢，ORM仍然力不從心。雖然能夠實現，可是不值的。視圖能夠解決大部分calculated column，case ，group，having,order by, exists，可是查詢條件(a and b and not c and (d or d))。。。。。。


        世上沒有驢是不吃草的(又想好又想巧,買個老驢不吃草)，任何優點的背後都隱藏着缺點，這是不可避免的。問題在於，咱們是否能容忍缺點。ADA代碼雖然易用性不好，可是US.DoD（the department of defense）欣賞他的運算速度；.net平臺很不錯，可是他是MS的。^_^

 ORM爲什麼而生

          在數月之前，我有幸參加了一個公司內部的組件發佈會。令我深感意外的事，一貫無人關心的組件發佈會此次變得人山人海，在漫長的新版本介紹以後。每一個開發組長都跳出來抱怨上一個版本的問題，而且宣佈與剛發佈的新版本也是沒法知足他們的須要的。一切都是如此的混亂，以致領導層不得不採用鎮壓的方式來平息怒火沖天的人們。


       在會後的那個晚上，我仔細回想了此次衝突。由於據我瞭解，這一系列的組件很是完美的完成了他所被期待的功能。但是爲何仍是會被抱怨如此那。


         我以爲，可能，他(組件)是沒有被正確使用了。


不知道還有誰記得James Elliott的那句話，

As good object-oriented developers got tired of this repetitive work, their typical tendency towards enlightened laziness started to manifest itself in the creation of tools to help automate the process. When working with relational databases, the culmination of such efforts were object/relational mapping tools.

    ORM構架只能是一個helper，他定位與此，而不是完整的數據持久層。他的設計者歷來就沒把他定位於取代一切的超級美女。ORM致力爲長久以來的程序員與」重複勞動」的戰爭而助拳。與任何一個helper同樣，他有本身的不足，他有優勢也有缺點。


       無數的開發人員試圖將使用ORM的框架構架本身項目的數據持久層，不少人感覺到了ORM的優點，他們歡心鼓舞。可是很不幸，也有不少人失敗或是深受蹉責。


         還有許多人，無奈的編寫着不少ORM不適合做的事情。其實想想，被本身捨棄了的之前的helper工具，難道真的一無可取了？


ORM與DB Helper Library：


      不少人可能都接觸過這類的helper，每一個公司都有本身的helper。許多Helper提供了不少的強大的功能，封閉交互底層，實體類支持，提供SQL翻譯功能。ORM比之這些Helper只是多提供了一層，他嘗試封閉的自動化的（或是映射文件）來實現關聯。之前，這都是咱們手打的。（靈活替換數據庫也算ORM優勢，）        問題就在與有些人發現封閉的自動化關聯知足他們須要了，因此ORM對他而言是成功的。而有些人發現封閉的自動化關聯不適合他們的項目，因此ORM被詬病。          寫到這裏，我想不用多言了。該結束了。          個人觀點是ORM試圖取代helper，爲此提供了更多的功能。他爲了應付更加嚴格和複雜的企業需求而不斷髮展，在不少狀況下，這些工具開始具備自身的複雜性，使得開發人員必須學習使用它們的詳細規則，並修改組成應用程序的類以知足映射系統的須要，使用它們所面臨的複雜性反而蓋過了所能得到的好處。在咱們的大部分項目中Helper依然是咱們構建數據持久層的主力，ORM或許在有些項目(模塊)中能夠獨攬一切，可是ORM（就目前而言）沒法面對一切考驗。