Entity Framework 4.1 之八：繞過 EF 查詢映射
原文名稱：Entity Framework 4.1: Bypassing EF query mapping (8)
原文地址：http://vincentlauzon.wordpress.com/2011/04/21/entity-framework-4-1-bypassing-ef-query-mapping-8/
- Entity Framework 4.1 之一 : 基礎
- Entity Framework 4.1 之二 : 覆蓋默認的約定
- Entity Framework 4.1 之三 : 貪婪加載和延遲加載
- Entity Framework 4.1 之四：復雜類型
- Entity Framework 4.1 之五：多對多的關系
- Entity Framework 4.1 之六：樂觀并發
- Entity Framework 4.1 之七：繼承
- Entity Framework 4.1 之八：繞過 EF 查詢映射
這是這了系列的最后一篇，我將討論如何繞過 EF 的查詢映射。
像所有優秀的框架一樣，EF 知道它并不能優秀到覆蓋所有的角落，通過允許直接訪問數據庫，EF 支持開放底層的 ADO.NET 框架。
有三個 API 支持：
- DbContext.Database.ExecuteSqlCommand
- DbContext.Database.SqlQuery
- DbSet.SqlQuery
第一個沒有什么特別，就像典型的 ADO.NET 中的 SqlCommand。
第二個有點意思。
我們可以使用這個方法直接將 SQL 命令發送到數據庫，不管是存儲過程，還是臨時的 SQL。與 ADO.NET 的區別在于它能夠將查詢結果的 DataReader 中的數據直接轉換為實體對象。
TElement 可以是任何類。重要的是 EF 不會跟蹤返回的對象，即使他們真的是實體類型的對象。這與第三個 DbSet 不同，第三種方式會跟蹤返回的對象。
讓我們試一下 DbContext.Database.SqlQuery:
{
return Database.SqlQuery<SprocReport>("SELECT LegalEntityBaseID, EntityName FROM dbo.LegalEntity");
}
一個最佳實踐就是在 DbContext 的派生類中封裝這些調用。下面是我們使用的 SprocReport 類的定義。
{
publicint LegalEntityBaseID { get; set; }
publicstring EntityName { get; set; }
}
這個類不是實體，而且屬性被直接映射：不能控制映射。即使你使用復雜類型，并且覆蓋了映射，這些覆蓋也不會起作用。
現在看 DbSet.SqlQuery，這個方法返回的實體將會被 EF 跟蹤修改，所以，如果你在這些返回的實體上做了修改，當 DbContext.SaveChanges 被調用的時候，將會被處理。從另一個方面來說，也不能覆蓋列的映射。
另外一個旁路 EF 映射管理的方法是使用 Entity SQL，記住 EF 將實體模型映射到物理的模型，在轉換到本地底層的數據存儲（例如 TSQL) 查詢之前，先將 LINQ 查詢被轉化到實體模型上（通過 eSQL 語法）。
舉例來說，我們可以創建實體集而不需要在 DbContex 中定義：
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<SimpleEntry>().HasEntitySetName("MyEntry");
modelBuilder.Entity<SimpleEntry>().ToTable("MyEntry", "man");
modelBuilder.Entity<SimpleEntry>()
.Property(s => s.ID)
.HasColumnName("SimpleEntryID");
modelBuilder.Entity<SimpleEntry>()
.Property(s => s.Name)
.HasColumnName("SimpleEntryName");
}
然后，我們可以暴露出查詢：
{
IObjectContextAdapter adapter =this;
var entries = adapter.ObjectContext.CreateQuery<SimpleEntry>("SELECT VALUE MyEntry FROM MyEntry");
return entries;
}
這里我們使用底層的 ObjectContext 以便查詢。這種方式比直接將 SQL 發送到數據庫的優勢在于，我們可以使用 LINQ 在其上進行查詢，最終發送到數據庫的 SQL 是合并得到的。因此，我們可以通過從一個返回任何結果的簡單查詢開始，然后在其上應用 LINQ來得到有效的查詢，而不需要在使用方查詢整個表。
為了說服我們自己，我剛剛說的是真的，讓我們試一下。
{
IObjectContextAdapter adapter =this;
var entries = adapter.ObjectContext.CreateQuery<SimpleEntry>("SELECT VALUE MyEntry FROM MyEntry");
var final = from e in entries
where e.Name == "Mark"
select e;
var f = (System.Data.Objects.ObjectQuery<SimpleEntry>)final;
var s = f.ToTraceString();
return entries;
}
如果輸出 s 的值，可以看到：
[Extent1].[SimpleEntryID]AS[SimpleEntryID],
[Extent1].[SimpleEntryName]AS[SimpleEntryName]
FROM[man].[MyEntry]AS[Extent1]
WHERE N’Mark’ = [Extent1].[SimpleEntryName]
這是 EF 生成的典型的 TSQL, 你會注意到 LINQ 過濾條件被應用到了 SQL 語句中。
現在，如果你希望能夠截獲實體的 Insert, Update, 和 Delete 操作，就要靠你自己了。你需要重寫 DbContext.SaveChanges ，獲取特定狀態的實體，實現自己的數據操作邏輯來保存修改，然后在調用 base.SaveChanges 之前將這些實體的狀態切換到 Unmodified 。這可以用，但這是一種特殊的技巧。
浙公網安備 33010602011771號