Entity Framework 實踐系列 —— 搞好關系 - 兩情相悅（雙向一對一，one-to-one）- 續(xù)
在上篇文章中，我們通過WithRequiredDependent或WithRequiredPrincipal實現(xiàn)了“雙向一對一”關系，但是Entity Framework生成的SQL語句很糟糕。
在上篇文章發(fā)布一個多小時之后，我們找到了解決之道。這就是寫博客帶來的好處，逼著你靜下心來深入思考。
問題的原因在于我們向Entity Framework傳遞了不合情理的“一對一”關系信息，把Entity Framework搞得暈頭轉(zhuǎn)向。BlogSite中有UserID，BlogUser中卻沒有BlogID，這是一個不平等的“一對一”?！皟汕橄鄲偂北緛砭褪窍嗷サ?、平等的，不存在誰依賴誰、誰主宰誰。男人心中有愛情密碼，女人為什么不能有？男人主動追求女人，女人為什么只能被動挨追？兩情相悅是兩顆心的交互，誰先感覺到，誰就主動些。
我們先回顧一下之前不平等的兩情相悅（一對一關系）：
注：BlogUser類中缺少BlogID屬性，BlogUser表中缺少BlogID字段。
看看真正的兩情相悅：
注：BlogUser類增加了BlogID屬性，BlogUser表中增加了BlogID字段，其他都沒動。
然后在OnModelCreating中通過Fluent API進行如下定義：
modelBuilder.Entity<BlogSite>()
.HasRequired(b => b.BlogUser)
.WithMany()
.HasForeignKey(b => b.UserID);
modelBuilder.Entity<BlogUser>()
.HasRequired(u => u.BlogSite)
.WithMany()
.HasForeignKey(u => u.BlogID);
運行測試，看看是否真的兩情相悅了：
測試通過！
接著，我們要看一看是否是完美的“兩情相悅”。打開Server Server Profiler，揭開“兩情”的真諦：
獲取一個BlogSite列表時執(zhí)行的SQL：
SELECT
[Extent1].[BlogID] AS [BlogID],
[Extent1].[BlogApp] AS [BlogApp],
[Extent1].[IsActive] AS [IsActive],
[Extent1].[UserID] AS [UserID],
[Extent2].[UserID] AS [UserID1],
[Extent2].[Author] AS [Author],
[Extent2].[BlogID] AS [BlogID1]
FROM [dbo].[BlogSite] AS [Extent1]
INNER JOIN [dbo].[BlogUser] AS [Extent2]
ON [Extent1].[UserID] = [Extent2].[UserID]
WHERE 1 = [Extent1].[IsActive]
取一個BlogUser列表時執(zhí)行的SQL：
SELECT
[Extent1].[BlogID] AS [BlogID],
[Extent1].[UserID] AS [UserID],
[Extent1].[Author] AS [Author],
[Extent2].[BlogID] AS [BlogID1],
[Extent2].[BlogApp] AS [BlogApp],
[Extent2].[IsActive] AS [IsActive],
[Extent2].[UserID] AS [UserID1]
FROM [dbo].[BlogUser] AS [Extent1]
INNER JOIN [dbo].[BlogSite] AS [Extent2]
ON [Extent1].[BlogID] = [Extent2].[BlogID]
這才是完美的兩情相悅！這才是“雙向一對一”關系的完美實現(xiàn)！
浙公網(wǎng)安備 33010602011771號