本篇是第一階段的完結篇。

學完這篇後，你應該可以利用MVC進行完整專案的開發了。

本篇主要講述多表關聯資料的更新，以及如何使用原生SQL。

文章提綱

• 多表關聯資料更新
• 如何使用原生SQL
• 總結

多表關聯資料更新

我們在第四篇文章已經講過資料的更新了，不過那個是針對單表結構的更新。

這次我們講下使用EF進行關聯資料的更新。

關聯資料更新有兩種情況：

1.一對多

2.多對多

第一種情況關聯表有主外來鍵關聯，只要簡單的更新外來鍵值就可以了（相當於更新單表），我們主要講解第二種多對多的情況。

使用之前很熟悉的模型：

我們定義一個場景：    

一個使用者可以有任意多個角色，一個角色可以有任意多個使用者。

我們接下來完成下面操作：

編輯某個使用者時，顯示該使用者的角色進行編輯。

即 更新某個使用者（SysUser表）及其相關的角色（SysUserRole表）。

詳細步驟：

1.先新增一個ViewModel, 用來表示角色是否分配給某個使用者。

2.開啟UserRoleController，新增一個Edit的Action用來顯示編輯頁面。

有兩點說明一下：

a.我們沿用上一篇文章的模型，多了一個SysDepartment，實際模型如下：

b.PopulateAssigenedRoleData將特定使用者下選中的角色標記出來。

3.開啟Views\UserRole\Index.cshtml, 增加一個編輯按鈕

4.再根據Edit Action自動生成Edit View

修改相關內容，主要是兩點：

a.部門

b.角色

角色是通過一組checkbox來顯示的。

Checkbox顯示資料庫中所有角色，已分配給使用者的會顯示選中狀態。

通過勾選checkbox的方式來實現使用者角色的更新。

說明

角色少這樣弄沒問題，如果多的話經典的做法，可以用兩個listbox,中間用箭頭將左右兩邊的選項移動。本篇文章主要說明關聯表的更新，後續文章我們會提供更好的做法的示例。

執行下Index頁面。

進入編輯頁面。

這樣編輯的顯示功能就已經完成了。

可以看到，用一組checkbox表示roles是否選中。

5.最後再完成HttpPost的Edit功能。

首先更新SysUser表：

用model binder中的值更新entity: userToUpdate.

可以看到，我們使用了白名單指定資料庫中需要更新的欄位。

TryUpdateModel(userToUpdate,"",

new string[] {"LoginName","Email","Password","CreateDate","SysDepartmentID"})

再更新SysUserRole表：

將資料庫中值和編輯後的值進行比對，基本邏輯是：

如果被選中了，原來沒有的要新增；

如果沒被選中，原來有的要刪除。

UpdateUserRoles(selectedRoles, userToUpdate);

注意在UpdateUserRoles裡，我新建了一個連線

using (AccountContext db2=new AccountContext())

如果用之前的db會報如下錯誤：

已有開啟的與此 Command 相關聯的 DataReader，必須首先將它關閉。

重新執行下Index, 如下一組圖，這時我們看到角色編輯已經起作用了。

至此，多表更新的示例就介紹到這，其他情況相信你可以舉一反三自己推匯出來做法。

使用原生SQL

使用EF的一個優點就是自動幫我們生成SQL，這在常規情況下很方便，但有些情況下用EF卻不適合。

例如我們上面更新SysUserRole這張表時，每次增減一條資料，要迴圈很多次。

另外還有些特別複雜的語句，利用EF很難生成。

EF提供一組方法用來執行原生的SQL.

有以下三種:

1.DbSet.SqlQuery

2.Database.SqlQuery

3.Database.ExecuteSqlCommand

這三種有啥區別呢？我們來看例子。

對三種形式我們各舉一例。

例子1：DbSet.SqlQuery查詢並返回Entities

我們開啟Controllers\AccountController.cs做實驗

找到Details方法

將註釋的部分改成方框部分即可。

方框中的和註釋掉的內容SysUser sysUser=db.SysUsers.Find(id)完全一樣。

前端顯示效果不變：

注意兩點：

1.構造帶引數的SQL語句（養成好習慣，防止SQL注入，總是用帶引數的SQL語句）

2.此處使用的是DbSet<TEntity>執行SQL方法，返回的直接是Entity， 和LINQ查詢一樣。如果暫時不熟悉LINQ，用這種方法替換（作為一個過渡），可以讓你快速的使用起新框架。

這種情況有一些缺陷，例如

SELECT LoginName as UserName,* FROM [dbo].[SysUser] WHERE [email protected]

大家可以看到我添加了LoginName as UserName，這是因為Model中用了Column Attribute，資料庫中存的欄位是LoginName

這樣我如果不轉換，model就會找不到匹配的欄位而出錯，而如果用db.SysUsers.Find(id) 就可以智慧轉換。

例子2 Database.SqlQuery 返回其他型別

string query = "select loginName from SysUser";

var names=db.Database.SqlQuery<string>( query).ToList();

以上會返回一個System.Collections.Generic.List<string>型別。

這種方式和第一種情況最大的區別就是返回non-entity 型別。

我們可以根據需要，自己構建需要的型別。

我們也可以自定義一個entity type讓它返回，例如類似我們上一個例子：

SysUser sysUser = db. Database.SqlQuery(query, paras).SingleOrDefault();

這樣也可以返回entity, 但要注意，這種方式將不會被context track, 返回後就沒關係了，如果我們在View中用類似於Model.XXX導航屬性獲取其他關聯資料就會報錯。例如@foreach (var item in Model.SysUserRoles)，這種情況下會報Model為null的錯誤。

例子3：Database.ExecuteSqlCommand執行更新語句

最後一個是更新的，直接看示例就明白了：

context.Database.ExecuteSqlCommand("UPDATE dbo.Posts SET Rating = 5 WHERE Author = @author", new SqlParameter("@author", userSuppliedAuthor));

最後提下執行儲存過程，也類似，我就不多說了，如下MSDN（https://msdn.microsoft.com/en-us/data/jj592907）截圖。

原生SQL使用總結

原生SQL執行查詢：

需要返回實體模型，使用DbSet.SqlQuery （context會跟蹤，等效於LINQ方式）

需要返回其他型別，使用Database.SqlQuery

原生SQL執行更新：

使用Database.ExecuteSqlCommand

至此，本系列文章的第一階段（1～10）就結束了，下一階段再見。

感謝支援，祝學習進步！

P.S. 方便大家觀看，列出系列文章地址：