EF 的霸氣配置

通過ef 作為運算元據庫的工具有一段時間了，也做了幾個相對不大的專案，慢慢的也對ef的使用摸索出來了一些規則，雖然說不是技術難點，但是，我說的是但是，能夠提高我們開發效率的棉花糖有時我們還是必須要吃的，因為他確實很甜很甜。現在ef已經更新到6.1.1了，從原來的5.0 到現在也不過是短短的一年多，所以說ef的生命力還是很強的。什麼你要我對比一下ef和nhibernate的優缺點，這不是本文的重點，我只說一句，ef側重**配置，nhibernate 側重配置檔案配置，但是說哪種好，蘿蔔白菜各有所愛吧。

剛開始使用ef運算元據表我們是這樣使用的，通過在dbcontext中新增dbset這種形式的屬性來實現，但是，我說的是但是，這種方式隨著我們的實體domain越來越多的時候我們不得不乙個乙個的新增到dbcontext中，這不禁讓我很苦惱，有沒有更好的辦法呢？

為了說明的方便，我建立了乙個控制台的程式，畢竟ef和具體的專案型別無關。

1  classprogram
2 9 }
10 11 public classtestcontext : dbcontext
12 23 return_instance;
24 }
25 }
26 27 private string_connectionstring;
28 29 public stringconnectionstring
30 37 return_connectionstring;
38 }
39 set
40 43 }
44 45 publictestcontext()
46 : base("name=testconn")
47 50 public testcontext(stringconnectionstring)
51 : base(connectionstring)
52 55 
56 /// 57 ///定義的實體
58 /// 
59 public dbsetpersons 
60 }
61 [table("person")]
62 public classperson
63 65 
66 public string age 
67 }

每次新增實體domain 都要在dbcontext 中新增乙個對應的屬性，很令人苦惱，並且如果屬性為string 型別，在資料庫中建立的表的長度為max，當然我們可以修改ef的預設約定來讓string 型別在資料表中具有一定的長度。我們有沒有更好的方式來控制ef建立的資料表呢，並且要易於維護，讓所有同事都可以很輕鬆的掌握。當然，有乙個新大陸被發現了。

我們通過反射來找到所有繼承自entitytypeconfiguration的類，這些類就是ef的對映類，我們把這些對映類新增到ef configuration中就可以實現我們的功能，說太多，上**。

1  classprogram
2 9 }
10 11 public classtestcontext : dbcontext
12 23 return_instance;
24 }
25 }
26 27 private string_connectionstring;
28 29 public stringconnectionstring
30 37 return_connectionstring;
38 }
39 set
40 43 }
44 45 publictestcontext()
46 : base("name=testconn")
47 50 public testcontext(stringconnectionstring)
51 : base(connectionstring)
52 55 protected override voidonmodelcreating(dbmodelbuilder modelbuilder)
56 67 
68 base.onmodelcreating(modelbuilder);
69 }
70 71 
72 }
73 74 public classbasedomain
75 78 [table("person")]
79 public classperson
80 82 public string name 
83 84 public string age 
85 }
86 89 public override voidinit()
90 {
91 this.totable("

EF 的霸氣配置

EF實體配置

EF6 x Oracle 配置問題

SQLite使用EF6的連線配置

EF 的 霸氣配置

EF實體配置

EF6 x Oracle 配置問題

SQLite使用EF6的連線配置

相關推薦

EF 的霸氣配置