跟我一起学.NetCore之EF Core 实战入门，一看就会
前言
還記得當初學習數據庫操作時，用ADO.NET一步一步地進行數據操作及查詢，對于查詢到的數據還得對其進行解析，然后封裝返回給應用層；遇到這種重復而繁瑣的工作，總有一些大神或團隊對其進行封裝，從而出現了很多ORM框架，讓小伙伴把更多精力放在業務處理上，同時更多的面向程序對象開發，對工作效率的提升有很大的幫助。
目前關于C#出現了很多ORM框架，比較流行的大概有FreeSql (國內)、SqlSugar (國內)、Dapper (國外)、EF/EF Core?(國外)、linq2db (國外)等，
當然也有一些小伙伴對其進行性能比較，各有優勢吧。從我個人及周圍的小伙伴使用來看，EF/EF Core和Dapper使用率相對比較高。這里就先說說EF Core，后續逮住機會再和小伙伴一起分享其他；
正文
隨著.NetCore的迅速推進，EF Core也緊跟其步伐。目前長期支持版本是EF Core3.1，而下一個穩定版本EF Core5.0將計劃隨.Net5一起發布，預計應該會在這個月(2020年11月)，可見微軟對EF Core是非常重視的；
對于之前用過EF的小伙伴，應該都知道，EF有三種開發模式：CodeFirst、ModelFirst、DbFirst，這三種根據業務需求及個人偏好用的相對比較多的是DbFirst和CodeFirst；現在EF Core推薦使用CodeFirst的方式進行項目開發，當然也可以通過反向工程的方式，以數據庫設計為先。這里都會針對這兩種方式進行舉例演示；
在項目中使用CodeFirst方式，這里用的數據庫是VS自帶的LocalDb，項目還是老規矩，一個WebApi項目；既然實戰入門，肯定得有點樣子才對，所以這里就簡單模仿了三層架構的形式進行舉例演示，如下項目結構：
項目依賴如下：
EFCoreTestDemo API項目依賴EFCoreTestModel和EFCoreTestService項目；
EFCoreTestService 服務層項目依賴EFCoreTestModel和EFCoreTestRespository項目；
EFCoreTestRespository?數據層依賴EFCoreTestModel項目
結構好了，現在開始敲代碼，比如模擬用戶維護的增刪改查吧；?既然是CodeFirst，先暫時把數據庫放一邊。?如下步驟開始：
做用戶維護，肯定得有用戶實體，先在Model層中增加一個用戶類；
接下來就要對數據進行操作，就是所謂的增刪改查，既然用到EF，肯定得有一個DbContext，這個和數據存儲有關，所以將其放在數據層；
其實到這一步，我比較喜歡先遷移一下，看看是否有問題，能否正常生成數據庫和對應的表；(其實這里可以不用急著遷移，繼續編碼的，但提前把問題扼殺在搖籃中是很不錯的想法)；
既然要遷移，肯定得把數據的連接字符串傳過去，這里是從WebApi項目的Startup中注冊服務時進行傳遞，并指定遷移程序為WebApi項目：
上圖中數據庫連接字符串從何而來的，自己寫的嗎？哈哈哈，拷貝過來的，這里順便把之前創建的數據庫都刪了，方便測試，如下圖：
遷移方式有兩種，一種是命令行的形式，另一種是在VS中的包管理器控制臺(PMC)進行；
命令行方式：需要安裝命令行工具，這里使用全局安裝方式，如下命令：dotnet?tool?install?--global?dotnet-ef
在指定的遷移程序集中安裝Microsoft.EntityFrameworkCore.Design，否則遷移不成功。遷移過程如下圖：
包管理器控制臺(PMC)方式進行遷移：需要在指定的遷移程序集中安裝Microsoft.EntityFrameworkCore.Tools包，否則遷移失敗：
遷移沒問題，繼續回到代碼邏輯；現在應該開始編輯業務代碼，即對用戶的增刪改查，先從數據層開始吧，具體步驟見下圖編號：
業務層：
控制器：
使用自帶依賴注入：
剩下的就是運行看結果啦，這里沒有繼承Swagger，使用Postman工具進行測試，如下圖：
通過以上步驟，使用EF Core的CodeFirst 從創建實體->遷移->最后業務編寫的流程基本就是這樣啦；后續如果新增實體，還是重復以上步驟。說完流程，接著說說上面過程中其他技術點↓↓↓
增刪改查操作
增加用戶案例，首先將原有對象進行包裝，然后通過標識包裝對象的狀態，最后通過SaveChanges進行統一執行操作，如下：
用戶的刪除、更新與新增時同樣的道理，如下：
查詢，一般通過DbContext自帶方法、Lamda表達式，或是Linq語句，同樣查出可追蹤的包裝對象，但是可以將其查詢設置為不可追蹤，有時候為了提高性能，會針對進行設置或整體設置：
整體設置不追蹤：
遷移命令
上面說到的遷移命令只有新增遷移和更新數據庫，還有一些常用的指令也比較常用，如下：
通常，生成環境下一般都會采用腳本的方式生成數據庫和表，那開發的時候是通過命令進行的，如何生成對應的腳本呢？?如下圖：
對于刪除遷移的場景，一般會是對當前遷移不滿意，比如字段寫錯了、類型誤用等情況，如下：
如上圖，新增遷移已經完成了，但是由于Age使用的類型不對，要廢棄這次遷移，重新進行遷移，當然也不可以不刪除，但對后續查詢歷史遷移記錄的時候會產生誤解。如下刪除最近一次遷移，如下：
表問題
在上面遷移的過程中，并沒有指定表明和字段及設置對應的列類型，是EF Core框架按照默認規則，自動幫我們生成了，是不是很貼心，但是既然是默認，框架肯定不知道我們到底需要什么，如下生成的表：
如上圖所示，EF Core框架默認將類名作為表明，生成的字符串長度都默認為最大，這些肯定不是我們想要的，所以作者肯定想到這，給我們提供了修改的方法，我們通常會采用注解的方式或是FluentApi的形式進行約束和更改，注解直接在對應列上標注，但一般會推薦使用FluentApi，相對比較靈活；在DbContext中的OnModelCreating中編寫對應代碼即可，如下：
然后重新遷移并更新到數據庫，如下：
Linq查詢
在EF使用的過程中，Linq應該是少不了的，估計有小伙伴會說，直接用DbContext中提供的方法和Lamda表達式就行啦，是，那肯定是可以的，只能說還沒用到精髓，哈哈哈，面向代碼編程的SQL查詢語句，用起來是很方便的，如下：
是不是看起來像SQL，雖然說是Linq新語法，但看著不陌生，用著也很方便；這里不打算深入說，只是給小伙伴們提上一嘴；那么無情嗎？當然不，我把之前收集到的Linq文檔已經上傳，小伙伴們可以參考一下：
官方文檔：https://docs.microsoft.com/zh-cn/dotnet/csharp/linq/?
收集文檔：
鏈接：https://pan.baidu.com/s/1BZivBXG9WT-gOqsXKG08Ng
提取碼：9qyu
反向工程(先有數據庫設計，然后根據數據庫生成對應Model)
對于一些項目，當小伙伴們接到手時候已經把數據庫設計好了，這種情況沒必要犟著一個一個實體敲，重新生成數據庫，完全可以通過數據庫反向生成代碼，反正怎么方便就怎么來；還有一種情況就是很多小伙伴還是比較喜歡數據庫優先的開發模式，直接反向工程就好啦；
這里用之前創建的數據和User表，然后建了一個test項目，里面只安裝了EF Core的核心包和Design包，如下：
同樣使用命令行或包管理控制臺都行，這里就使用命令行，在test項目目錄下執行以下命令(這里是SqlServer，還需要安裝Microsoft.EntityFrameworkCore.SqlServer包)：
以上命令簡單說明：
dotnet ef dbcontext scaffold后面指定數據庫連接字符串；
第二個參數代表是對應數據庫指定的Provider，及對應數據庫對應的Nuget包；
-o：代表是生成的實體類存放的位置；
--context：生成的dbContext的類名稱；
--context-dir：指定生成的dbContext存放的位置；
-f：覆蓋現有文件；
-v：顯示遷移過程及報錯信息；
-t：指定表反向生成代碼,如果不指定代表所有表都生成；
-n：指定生成類名的命名空間，這個EF Core5.0提供；
—context-namespace:指定生成DbContext的命名空間，這個EF Core5.0提供；
注：生成的類和DbContext可以根據參數最終生成到對應位置，滿足自己需求。
如果是MySql，需要安裝Pomelo.EntityFrameworkCore.MySql包，其他步驟都一樣，這里就不演示了，就留給小伙伴練習吧；真的不要嫌簡單，只有親手做了，遇到問題，然后解決，最終才能提升，親身體會。
總結
這里只是簡單說說EF Core的使用，遷移流程及反向工程操作分享，其他的進階使用會陸續分享，小伙伴們也可以自己去加強，我這里有的資源，都會進行分享；說到這，后續文件下載地址大家只能在公眾號聊我啦，前兩篇由于博文帶文件下載地址，有些博客平臺把我禁言了，很是尷尬，不過修改申訴過啦。
博文源代碼地址：https://github.com/zyq025/DotNetCoreStudyDemo
一個被程序搞丑的帥小伙，關注"Code綜藝圈"，識別關注跟我一起學~~~
擼文不易，莫要白瞟，三連走起~~~~
總結
以上是生活随笔為你收集整理的跟我一起学.NetCore之EF Core 实战入门，一看就会的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET架构小技巧（8）——优待异常
- 下一篇： asp.net ajax控件工具集 Au