DIY.NETORM架構——總體分析

標籤：隱藏   nts   模組設計   關係型資料庫   核心   屏蔽   衡量   ref   font   

一、故事

      近些年一直開發MIS系統，用過PB，VB，C#  。如今學了半年的java，早先聽人說，.NET和 java一直就是互相借鑒。一起升級。都是為了讓程式開發趨於簡單，高校，而這不可避免就肯定用到架構，對java中非常多架構的實現原理。我也比較感興趣，在本系列的部落格正，咱們將一起實現一個簡單的.NET版 ORM架構。

      有人會有疑問。網上有非常多成熟的ORM架構，為什麼不直接用。偏偏要自己做一個呢？

      對於這個答案。是仁者見仁的問題，就好似建造大廈，假設他停留在會照著圖紙建房子，他肯定是個工人，而假設他能瞭解圖紙上的原理。那麼他必定是一個管理者。當他瞭解原理且能自己畫出一份圖紙的時候。他就是設計師！

 

二，技術瞭解

 

1．什麼是ORM?

 

      ORM，即Object-RelationalMapping（對象關係映射）。它的作用是在關係型資料庫和業務實體物件之間作一個映射，這樣，我們在詳細的操作業務對象的時候，就不須要再去和複雜的SQL語句打交道，僅僅需簡單的操作對象的屬性和方法。

 

2.ORM 優缺點

展開說說

長處：

（1），隱藏了資料訪問細節。

 

 

      “封閉”的通用資料庫互動。ORM的核心。

他使得我們的通用資料庫互動變得簡單易行。而且全然不用考慮該死的SQL語句。

高速開發，由此而來。

 

 

（2），ORM使我們構造固化資料結構變得簡單易行。

 

 

        回憶我們沒有ORM的年代。我們要為每一個表編寫形形色色的sql語句，我們拿到的資料內容。要自己轉換為對象。我們為了某個欄位值寫錯的bug徹夜不眠。而如今，基本上全部的ORM架構都提供了通過物件模型構造關聯式資料庫結構的功能。而這，“太好了！。！”。

缺點：

（1）犧牲效能：

 

 

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

 

 

（2）查詢語言：

 

 

        物件導向的查詢語言(X-QL)作為一種資料庫與對象之間的過渡,儘管隱藏了資料層面的業務抽象,但並不能全然的屏蔽掉資料庫層的設計,而且無疑將添加學習成本.

 

 

（3）複雜查詢：

 

 

        對於複雜查詢。ORM仍然力不從心。儘管能夠實現，可是不值的。

視圖能夠解決大部分calculatedcolumn。case ，group，having,order by, exists。可是查詢條件(a and b and not c and (d ord))我們有些也要謹慎考慮和又一次編寫sql語句！

 

總結：世上不論什麼事情是完美的。不論什麼優勢的背後都隱藏著缺點。這是必定的。問題在於，我們是怎樣平衡他們的額。在簡答業務的場合下，簡單三成可能就是最佳選擇，而在某些商務邏輯複雜，Team Dev龐大的項目中，ORM卻又是個不得不考慮的問題，詳細怎麼辦？就看你怎麼衡量，沒人說用了ORM就不讓底層人員寫sql語句了…………

三。模組設計構想

四、本篇總結

     本次簡單講述了ORM實現的基本思路分析及ORM架構使用的優缺點及在項目中怎樣合理的分析與應用。

我們用ORM架構是來解決這個問題。可是。不是什麼問題都是一種架構能夠解決的。資料庫的封裝。ORM僅僅是做了當中的工作。也不要認為這個東西是多麼的高深，隨著我們代碼的不斷推進。我們設計的不斷完好。事實上我們能夠發現。全部的代碼都是基本技術的組合，僅僅是我們對於他的組合形式不熟悉，相信自己。架構我們也是能夠寫出來的！

附件（系列部落格連結）：

     1，DIY.NETORM架構——總體分析

DIY.NETORM架構——總體分析