3/3/2009 3:48:15 AM

EF#3. Entity & Inheritance

Microsoft.NET | C# | Entity Framework | ORM | SQL | 技術隨筆 | 物件導向 Facebook Share

繼承 (inheritance) 是物件技術的核心,就是這個特性提供了 OOP 絕大部份的特色。這東西被拿掉的話,OOP就沒這麼迷人了。繼然談到了 ORM,就不能不來看看 R(關聯式資料庫) 怎麼被對應到 O(物件),同時還能處理好繼承關係。

RDBMS 連基本的物件 (Object Base) 都不支援了,更別說物件導向 (Object Oriented) 了。因此要搞懂 ORM 及繼承的關係,就得先瞭解基本的 OO 是怎麼實作 "繼承" 這個動作。這些知識是古早以前學 C++ 時唸到的,現在的 CLR 不知道有沒有新的作法? 不過應該大同小異吧! C++ 主要是靠 virtual table 來實作繼承關係,當子類別繼承父類別時,父類別定義的 data member 跟 method 就全都遺傳到子類別身上了,這動作就是靠 virtual table 作到的。細節我就不多說了,有興趣的讀者們請先上網找找相關資訊看一看。

ORM 的運氣好多了,只要處理資料的部份。因此前一段提到的 virtual table 如果要拿來應用也會簡單的多。virtual table 可以很直覺的想像成是 DBMS 裡 table schema 的定義,而一個物件 (instance) 的 virtual table 資料,正好就對應到該 table (DBMS) 的一筆資料。這正好是 ORM 基本的動作。大部份 OO 的書都會說,繼承就是 " Is A " 的關係。在資料上則是子類別擁有父類別所有的欄位定義。這很容易對應到資料庫的正規化,該如何切割資料表的規責。你可以切開靠 PK / FK 再併回來,或是直接反正規化讓它重複定義在多個 TABLE... 事實上,兩大 ORM (EF & NH) 都歸納出三種作法,後面來探討一下彼此的差異...

再來看看繼承關係,假設父類別 class A 對應到 table A, 那麼衍生出的子類別 class B 對應的 table B, 則應該要包含所有 table A 定義的欄位才對。從這點出發,就帶出了第一種作法: 就是把 table A 所有的欄位都建一份到 table B (註: table per concrete type)。

不過這樣看起來有點蠢,DBMS 熟悉的人也許會採另一種作法: 沒錯... table B 只要留個 foreign Key, 指向 table A 的 primary Key,需要時再 join 起來就好了,這是第二種作法 (註: table per type)。

唸過 DBMS 的人都還記得 "正規化" (normalization) 跟 "反正規化" 吧? 切割過頭也是很麻煩的,因此有第三種作法逆其道而行,就是建一個 table 給所有的子子孫孫類別共用。因此 table 需要的欄位,就是所有的子類別的所有欄位集大成,通通都建進來... 不用的話就空在那裡,這是第三種作法 (註: table per hierarchy)。

這三種作法,在 Entity Framework (以下簡稱 EF) 或是 NHibernate (以下簡稱 NH) 都有對應的作法,只不過名字不大一樣... 這篇 ADO.NET team blog 借紹的還不錯,可以參考看看。這三種方式,在 EF 裡的說法分別是 (括號裡是 NH 的說法,參考這篇: Inheritance Mapping):

  • Table per Hierarchy (NH: Table per class hierarchy)
  • Table per Type (NH: Table per subclass)
  • Table per Concrete Type (NH: Table per concrete class)

事時上,處理方式大同小異,不外乎用三種不同的對應方式,來處理物件繼承關係。這些不同類別的物件彼此有繼承關係,對應到 TABLE 的方法不同,各有各的優缺點。其實 ADO.NET team blog 講的都很清楚,我就不再多說,簡單列張比較表:

  適用於 不適用於
Table Per Hierarchy
  1. 最簡單的實作方式
  2. 所有同系類別的實體 (instance) 數量不會很多時
  3. 需要用單一 QUERY 查出所有的子類別物件時
  4. 繼承階層較簡單的情況
  5. 類別的欄位要調整很容易
  1. instance數量太多,會嚴重影響效能
  2. 無法在table schema上做太多嚴格的檢查
Table Per Type
  1. 繼承關係清楚的對應到 TABLE
  2. 需要用單一QUERY查出所有子類別的物件
  3. 不同於 TPH,可以針對每種類別,設定嚴僅的 table constraint
  4. 每個類別要變動或調整都很容易
  1. 繼承階層較多時,要取得單一 instance data 需要透過多層 join
  2. table 數量會隨著類別的數量快速增長
Table Per Concrete Type
  1. 綜合 TPH / TPT 的優點 (也綜合了兩者的缺點)
  2. 可以針對每種類別設定 table constraint
  3. ORM mapping 很簡單
  1. 要用單一QUERY查出所有子類別的物件並不容易 (需要把所有的 TABLE JOIN 起來)
  2. 父類別的欄位調整很麻煩,所有的 TABLE 都需要配合調整

 

[未完待續] to be continue…



1/23/2009 12:09:53 AM

EF#2. Entity & Encapsulation

Microsoft.NET | C# | Entity Framework | ORM | SQL | 物件導向 Facebook Share

前一篇講了一堆大道理,這篇就來看一些實作吧。各種 ORM 的技術都有共同的目的,就是能把物件的狀態存到關聯式資料庫,而這樣的對應機制則是各家 ORM 競爭的重點,勝負的關鍵不外乎是那一套比較簡單? 那一套包裝出的 Entity 物件能夠更貼近一般的物件?

會有這樣的 "對應" 機制需求,原因只有一個,物件技術發展的很快,已經能解決大多數軟體開發的需求了,不過資料庫就沒這麼幸運,現在的 DBMS 撇開一些技術規格不談,本質上還是跟廿年前差不多,就是關聯式資料庫而已,本質上就是一堆 table + relationship, 配合 SQL 語法來處理資料。發展至今,物件技術跟資料庫技術能處理的問題,已經是兩個完全不同世界的問題了,三層式的架構在這段出現斷層...。

解決方式大概有兩條路,一種就是想辦法把這兩個世界串起來,就是 ORM framework 想做的事。另一個就是改造 RDBMS,讓 RDBMS 進化成也具有物件導向特性的資料庫。不過以眼前的五年十年來看,ORM 還是大有可為。ORM 只要能把 "對應" 這件事做到完美的地步,其實在某個層面上就已經做到 OODB 的願景了,只差在這些物件是活在 APP 這端,不是活在資料庫那端...。

扯遠了,接下來我會試著從物件技術的三大核心 (封裝、繼承、多型),及資料庫最需要的查尋機制 (QUERY) 來看看 Entity Framework 各能提供什麼支援,才能客觀的評論 Entity Framework 值不值得你投資在它身上。

在繼續看下去之前,請先俱備基本的 Entity Framework 運用的能力。在 MSDN 名家專欄裡 MVP(朱明中) 寫的這幾篇我覺的很不錯,可以參考看看。我就是看這幾篇入門的 :D。幾年前在比賽上碰過他幾次,我還蠻配服他的,可以靠自學而有今天的成就。以下是他寫的幾篇 ADO.NET / Entity Framework 的系列文章:

  1. 讀寫 ADO.NET Entity Framework (2007 年 9 月)
  2. 由 LINQ 存取 ADO.NET 物件 (2007 年 9 月)
  3. 整合 ADO.NET Entity Framework 到應用程式中 (2007 年 9 月)
  4. 首次接觸 ADO.NET Entity Framework (2007 年 9 月)
  5. ADO.NET Entity Framework 概觀 (2007 年 9 月)

 

在開始之前,我們先來看看一個最簡單的 Entity Framework 的範例,然後來看看封裝性能夠對你的程式帶來什麼影響? 先來看看只用到了 ORM 卻沒發揮封裝性的例子:

image

這是存放會員資料的表格,對應的 TABLE 很簡單,SQL 如下:

[copy code]
   1:  CREATE TABLE [dbo].[Users](
   2:    [ID] [nvarchar](50) NOT NULL,
   3:    [PasswordHash] [image] NOT NULL,
   4:    [PasswordHint] [nvarchar](100) NOT NULL,
   5:    [SSN] [nchar](10) NOT NULL,
   6:    [Gender] [int] NOT NULL,
   7:   CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED
   8:  ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

 

大部份的人在 EDMX Designer 裡把資料表拉進來後,就開始用這個 Entity Class 了吧? 密碼的部份為了安全及實作上的考量,DB只存放 HASH,而 HASH 的運算則透過 .NET 程式來計算,不透過 SQL 的函數。作法決定後,你可能會寫出這樣的程式碼:

建立帳號的程式碼[copy code]
   1:  // 準備 object context
   2:  using (Membership ctx = new Membership())
   3:  {
   4:      // create user account:
   5:      User newUser = new User();
   6:      newUser.ID = "andrew";
   7:      newUser.PasswordHint = "12345";
   8:      newUser.PasswordHash = HashAlgorithm.Create("MD5").ComputeHash(Encoding.Unicode.GetBytes("12345"));
   9:      newUser.SSN = "A123456789";
  10:      newUser.Gender = 1;
  11:      ctx.AddToUserSet(newUser);
  12:      ctx.SaveChanges();
  13:  }

 

檢查密碼的程式碼[copy code]
   1:  // 準備 object context
   2:  using (Membership ctx = new Membership())
   3:  {
   4:      string passwordText = "12345";
   5:      User curUser = ctx.GetObjectByKey(new EntityKey("Membership.UserSet", "ID", "andrew")) as User;
   6:      bool isPasswordCorrect = true;
   7:      {
   8:          byte[] passwordTextHash = HashAlgorithm.Create("MD5").ComputeHash(Encoding.Unicode.GetBytes(passwordText));
   9:          if (passwordTextHash.Length != curUser.PasswordHash.Length)
  10:          {
  11:              isPasswordCorrect = false;
  12:          }
  13:          else
  14:          {
  15:              for (int pos = 0; pos < curUser.PasswordHash.Length; pos++)
  16:              {
  17:                  if (passwordTextHash[pos] != curUser.PasswordHash[pos])
  18:                  {
  19:                      isPasswordCorrect = false;
  20:                      break;
  21:                  }
  22:              }
  23:          }
  24:      }
  25:      Console.WriteLine("Password ({0}) check: {1}", passwordText, isPasswordCorrect ? "PASS" : "FAIL");
  26:  }

 

這樣的 User 類別設計有什麼問題? 我列幾個我認為設計上不妥的地方:

  1. 直接提供 PasswordHash 曝露過多不必要的實作細節
  2. 在台灣,身份證字號 (SSN) 跟性別 (Gender) 是相依的欄位 ( functional dependency )

以物件導向的角度來看,User 真正要提供的是接受 "驗證密碼" 的要求,至於你的實作是提供明碼或是用 Hash, 都是實作的細節。提供原始未加密的密碼,或是提供處理過的 HASH,在需求上都是不必要個功能。物件的介面定義要盡量以能滿足需求的最小介面為原則,其它的都不要公開,才滿足 "封裝性" 的要求。因此良好的設計應該把這些細節封裝起來,只在公開的介面表達你要提供的功能。

另外依照台灣的身份證字號規則, SNN 跟 Gender 是連動的。目前 User 的設計是把兩者的關係丟給前端寫網頁的人來維護,一不注意就會發生不一致的情況。DB 對於這種問題的解決方式,不外乎寫 trigger 或是其它 constraint 的方式來阻擋不正確的資料被寫入 DB,不過看了前面提到的規則,要單純用 SQL 的功能完整實作出來,還不大容易。

另一種作法,只儲存 SSN,Gender 欄位則以 VIEW 的方式提供,這樣就不會有不一致的問題。不過這方法的缺點在於,當邏輯太複雜的時後,常常會超出 SQL 能處理的範圍,效能也許會是個問題,或是 constraint 不能完全跟程式端一致。

就我看來,這類看似應該在 data layer 實作的複雜邏輯,又難以在 SQL DB 上面解決的問題,才是 Entity Framework 的強項。現在來看看 Entity Framework 能怎麼解決這些資料封裝的需求:

首先,把不需要公開的細節改成 Private 隱藏起來,包括 PasswordHash 的 Getter / Setter, Gender 更名為 GenderCode, 同時把 Getter / Setter 也改為 Private ...

接下來就要把這些封裝起來的細節,提供另一組較合適的公開資訊的方式。這時 .EDMX designer 替我們產出的 code 就能搭配 partial class 擴充功能了。來看看我們在 partial class 裡寫了什麼?

User.cs 的內容 (partial class)[copy code]
   1:  public partial class User
   2:  {
   3:      public string Password
   4:      {
   5:          set
   6:          {
   7:              this.PasswordHash = this.ComputePasswordHash(value);
   8:          }
   9:      }
  10:      public bool ComparePassword(string passwordText)
  11:      {
  12:          byte[] hash = this.ComputePasswordHash(passwordText);
  13:          // compare hash
  14:          if (this.PasswordHash == null) return false;
  15:          if (hash.Length != this.PasswordHash.Length) return false;
  16:          for (int pos = 0; pos < hash.Length; pos++)
  17:          {
  18:              if (hash[pos] != this.PasswordHash[pos]) return false;
  19:          }
  20:          return true;
  21:      }
  22:      public GenderCodeEnum Gender
  23:      {
  24:          get
  25:          {
  26:              return (GenderCodeEnum)this.GenderCode;
  27:          }
  28:      }
  29:      partial void OnSSNChanging(string value)
  30:      {
  31:          // ToDo: check ssn rules.
  32:          // sync gender code
  33:          this.GenderCode = int.Parse(value.Substring(1, 1));
  34:      }
  35:      private byte[] ComputePasswordHash(string password)
  36:      {
  37:          if (string.IsNullOrEmpty(password) == true) return null;
  38:          return HashAlgorithm.Create("MD5").ComputeHash(Encoding.Unicode.GetBytes(password));
  39:      }
  40:  }
  41:  public enum GenderCodeEnum : int
  42:  {
  43:      FEMALE = 0,
  44:      MALE = 1
  45:  }

 

被隱藏起來的 PasswordHash, 公開的介面就用 Password 的 Setter 跟 ComparePassword( ) method 取代,明確的用程式碼告訴所有要用它的 programmer:

"密碼只准你寫,不准你讀 (read only)... 只告訴你密碼對不對, 不會讓你把真正的密碼拿出去"

另一個部份,就是身份證字號跟性別的問題,則改用另一個方式解決。SSN 這個屬性維持不變,在它被更動時就一起更動 GenderCode 這個欄位。GenderCode 完全不對外公開,公開的只有把 int 轉成 GenderCodeEnum 的屬性: Gender。同時為了保護資料的正確性,只開放 Getter, 不開放 Setter。

 

同樣的程式,在我們調整過 Entity 的封裝之後,再來重寫一次看看:

建立新的使用者帳號[copy code]
   1:  // 準備 object context
   2:  using (Membership ctx = new Membership())
   3:  {
   4:      User newUser = new User();
   5:      newUser.ID = "andrew";
   6:      newUser.PasswordHint = "My Password: 12345";
   7:      newUser.Password = "12345";
   8:      newUser.SSN = "A123456789";
   9:      ctx.AddToUserSet(newUser);
  10:      ctx.SaveChanges();
  11:  }

 

 

檢查密碼是否正確[copy code]
   1:  // 準備 object context
   2:  using (Membership ctx = new Membership())
   3:  {
   4:      EntityKey key = new EntityKey("Membership.UserSet", "ID", "andrew");
   5:      User user = ctx.GetObjectByKey(key) as User;
   6:      // 要比對的密碼
   7:      string passwordText = "123456";
   8:      bool isPasswordCorrect = user.ComparePassword(passwordText);
   9:      Console.WriteLine("Password ({0}) check: {1}", passwordText, isPasswordCorrect ? "PASS" : "FAIL");
  10:  }

 

修改過的程式簡潔多了。不過比少打幾行程式碼更重要的是,它的邏輯更清楚,更不容易出錯。如果沒有妥善的處理封裝性的問題,可以想像寫出來的程式一定亂七八糟。要嘛不正確的資料都會被寫進 DB,不然就是 DB 有作適當的防範,但是程式沒有作好,最後就是到處都出現 SqlException ...

這裡只是簡單示範一下 Entity Framework 如何替資料提供封裝的特性,後續的文章會繼續示範 Entity Framework 如何能把 DBMS 的資料,進一步的應用到物件技術的繼承及多型等特性。敬請期待下集 :D



9/27/2008 2:04:00 AM

令人火大的 SQL 字元編碼...

SQL | TROUBLE SHOOTING | 不爽 Facebook Share

今天同事有個問題搞不定,就找我去處理,越弄越火... 嘖嘖,這裡就來還原一下現場,記錄一下這個鳥問題...。

最討厭處理這種問題了。現在客戶 IT 都委外,結果就變成 IT 本身不大管事,什麼事就交給外包商就好... 而這種 A 包商跟 B 包商之間的問題,往往就變成踢皮球... 除非有明確證據指出人就是他殺的,不然? 出問題的一方自己摸摸鼻子吧。幾年來吃了不少這種虧,這就是小廠的悲哀啊。

這次碰到的例子是客戶 A 系統建的資料,需要整理後匯到我們負責維護的 B 系統。而中間資料需要作些修正,所以建了一個中繼資料庫,透過 LINKED SERVER,從 A 系統的 DB 把整個 TABLE SELECT 一份到中繼資料庫,然後再進行一連串的修正...

 

image

一開始問題很單純,就兩邊碰到中文字編碼不同,直接 SELECT 就碰到這樣的亂碼..

 

image

看起來是個小問題,請對方 IT 確認了編碼的問題後,我在中繼資料庫作了點調整,convert 成 ntext 就搞定了。已經可以跑出正確的中文資料了。

正想把程式弄一弄就收工,然後很得意的回報問題搞定時,發現不大對勁,怎麼整個 BATCH 跑下來結果還是錯的? 還錯的不一樣? 真是奇了... 原本轉 UNICODE 問題,再怎麼樣也應該只是變亂碼,或是變 ? 而以,結果這次看到的是資料錯亂,跑出其它的字出來...

 

image

這張圖是我把問題簡化後抓到的,原本是有上百行的 SQL SCRIPT ... @_@ 被我抽絲撥繭剩這段。第 33 筆資料是有問題的,不過出現的資料不是原本 "馥瑈" 啊,原本是第二個字變成 ? 而以... 現在竟然變成上一筆資料 (第32筆) 的內容,而第三個字 '榮' 則是由前面好幾筆的 "XX榮" 留下來,第四個字 "子" 就真的不曉得從那裡來了...

 

好怪的問題,如果是程式碰到這種 BUG,一看就像某個 BUFFER 沒清掉就一直重複被使用,後面的值直接蓋掉前面的值,字串長一點沒被蓋掉,就這樣留下來了。而到了第 33 這筆不知為什麼原因,整個 BUFFER 的內容就跑出來... 這段 SQL SCRIPT 跟本沒作什麼事,不過是前面的 SELECT 指令,改 SELECT INTO 到 TEMP TABLE,然後再撈出來而以。直接 SELECT 沒問題,沒道理 SELECT INTO 就掛掉啊! 不過還真的被我碰到了,see the ghost ..

 

我沒有直接拼下去 GOOGLE 或是試各種解法,而是想了一下問題是怎麼回事? SQL / DB 的東西我只算外行人,沒本事跟他硬碰硬,我也不知道有啥工具可以看 SQL NATIVE CLIENT 的 TRACE INFO 之類的,只能靠想像,猜一下問題會在那。一開始我就否定掉是不是什麼編碼或是定序的問題,因為我可以正確的 SELECT 出來啊,而且如果 SELECT INTO 是變成 ?? 的話我也許還會頭痛一點,不過竟然是上一筆的資料跑過來了? 這個問題很明顯的,跟本就是 overflow (緩衝區溢位) 之類的 BUG。八成是什麼地方應該填個 0x00 作字串結尾的 CODE 錯掉,結果 SQL 就抓過頭,抓到不該抓的舊資料才會這樣。

 

拿我寫了十幾年程式的經驗,跟它賭下去了!!  於是我就沒再去跟一堆編碼定序之類的設定搏鬥了,因為我認定這是 SQL SERVER 或是 SQL NATIVE CLIENT 的 BUG。我採的方案是找可以繞過去的方式,於是我把我想的到的 COPY TABLE 都用上了,最後試出來的是笨方法...

 

用... 用... 用 CURSOR 一筆一筆的跑... @_@

 

哈哈,各位看倌請笑小聲一點,我這貴州的驢子就只會這種把戲而以.... 果然這樣就正確了。CURSOR 的 FETCH 指令,把欄位的值抓到 nvarchar 的變數,就一切 OK,然後再把這變數的值 update 回我的暫存 TABLE,就什麼問題都沒了 -_-

 

真是它ㄨㄨㄨㄨ的,最後的 SOLUTION 細節我就不一一的貼出來了,反正只是換個方式 COPY TABLE 而以。既然我賭是 M$ 的問題,而換條路的方式 (完全沒改任何定序 OR 編碼) 也成功了,我就不跟它奮鬥下去了,客戶的 IT 既然懶的上 UPDATE / SERVICE PACK,我也只好避掉問題了事... 咳咳。特地貼出來記念一下,如果你們也碰到一樣的問題,切記切記,別跟它硬碰硬啊... :D






精選文章

RUN! PC 文章及範例下載
2008/11. 生產線模式的多執行緒應用
2008/09. 用ThreadPool發揮CPU運算能力
2008/06. SEMAPHORE在ASP.NET的應用
2008/04. 以ASP.NET開發同步WEB應用程式

如何學好 "寫程式" 系列
#1. 該如何學好 "寫程式" ??
#2. 為什麼 programmer 該學資料結構 ??
#3. 進階應用 - 資料結構 + 問題分析
#4. 你的程式夠 "可靠" 嗎?

#5. 善用 TRACE / ASSERT

安德魯是誰?

Andrew Wu | Create Your Badge

我喜歡鑽研物件導向、軟體工程及作業系統等相關技術。我會在這裡發表我的研究心得,也當作我自己的學習筆記。


Recent comments

Comment RSS