ORM

（好吧，這篇文章貌似進入了一個誤區，先mark下，查看資料再行修改）

在MVC盛起的年代，因爲本人負責維護的公司系統是ORM架構，致使不得已須要耗費一些時間在已經「過期」的技術上面~object relational mapping，「傳統」的三層架構。由界面、邏輯層、數據層（或者稱：UI、業務邏輯層、數據鏈接層），將邏輯層和數據層分開的方法讓結構更明顯，更清晰（雖然暫時我還不是這麼以爲，感受好像時間都花在了編寫bin）

通常來說，由於數據庫領域的實體聯繫模型與面向對象領域的領域模型都是用來對業務邏輯進行建模的，所以最好保持二者一致，不然若是兩個領域的技術人員各自立山頭，就必然出現領域模型的持久化困境。我私下猜想， ORM 這個東西的出現就是緣於兩個領域的人各執己見：對象領域的人在對領域建模時，想搞 「 富模型 」 以彰顯本身對對象技術的深度應用能力；數據庫領域的人在對領域建模時，則追求無冗餘的優雅關係設計以彰顯本身的數據庫設計能力，兩拔人都不願讓步。但對象總得有個容身之處啊，因而只好搞出個能把兩部分 「 阻抗不匹配 」 銜接起來的東西，天然這東西就是 ORM 。

我認爲 ORM 就是個怪胎。良好的領域建模應該在數據庫的 「 實體 —— 聯繫 」 層面和對象的 「 模型 」 層面儘量作到一致。所以當遵循這種策略時，數據持久方式就是：對象專家進行讓步，放棄 「 富模型 」 形成的持久化操做困難；數據庫專家升級，以 「 實體聯繫模型 」 作爲建模準則，放棄一些嚴格的範式限制。

可是這樣的方法仍是出如今咱們的某個開發階段，廢話很少說，就其進行說明吧。

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

主要部分有兩個封裝（一下稱爲A&B），在A中，對類進行定義和數據操做，數據的交互（insert,update,delete...）部分由Grove.ORM中提供的公共類可操做，【PS：可類比於LINQ的用法（PPS：待驗證）】因此A的封裝.BLL實現的是model類別，實現數據存取。而在B中，相似於邏輯層，在從A封裝中取出數據還有重寫數據實現邏輯層的輸出，因爲少了不少的數據層存取的代碼顯得要「瘦」不少。將封裝的類引入到BIN中就能夠對其方法進行調用，在頁面的邏輯層就能夠大量的省去代碼實現數據存取，避免重複寫入動做。好比我修改一個簡單的web application的時候，因爲是傳統的webForm架構，數據就寫在頁面的.cs檔中，每個欄位的值在從數據庫中取出的時候都讓人好難受，我須要寫一大段的SQL去完成，反覆的重寫動做，讓人精神上開始崩盤，再加上本人離譜的粗心度，在測試時不斷修改SQL和重寫的確花費了大量的時間。在這樣的ORM架構中，維護就不會有這樣的問題，數據的問題，我直接轉向A類庫中，重寫資料輸出的內容，我轉向B類庫中，而其餘業務邏輯層實現的問題，在.aspx.cs檔案中進行修改，大大的減小了維護的時間，即便這個結構讓人很不舒服。

他的架構一目瞭然，可糾結於他的這樣的繁瑣的過程，讓人多少有些不自在。

總結的過程當中，我總會發現一些有意思的事情，各類架構不斷地更新成長，而咱們若是不更新本身的軟件，很難跟上時代，webForm-->ORM-->MVC 要知道一項新的技術出現，你須要知道他出現的理由和價值，才知道本身是否值得花足夠的時間去學習。就像不少男生愛玩的遊戲dota同樣，當全部人都在happy 6.70c的時候難道你還抱着6.48的地圖happy單機麼？what a joke~！

IT技術如同股市同樣，入手有風險，學習需謹慎！！！

（結構亂了一點，只是簡單介紹下過分的結構ORM）

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

從這裏從新書寫對O/RM的認識~

這是一種關係映射到數據庫的鏈接方式，和上述說明的架構是不一樣的概念。在咱們熟悉的LINQ中，就是使用的這種對象關聯到SQL數據的概念！以下段代碼~

using System.Data.Linq;
using System.Data.Linq.Mapping;
        [Table(Name = "Customers")]
         public class Customer
        {
                [Column(Name = "customerName")]
                 public string CustomerName { get; set; }

                [Column(Name = "email")]
                 public string Email { get; set; }
        }

該對象裏面包含了， 屬性直接對應數據庫中的字段的操做，且提供了一些基本的add/edit/update/delete操做~~~

因此O/RM是一種數據和對象的關聯方法~

（待續）