ASP.NET MVC應用遷移到ASP.NET Core及其異同簡介

　　ASP.NET Core是微軟新推出支持跨平臺、高性能、開源的開發框架，相比起原有的ASP.NET來講，ASP.NET Core更適合開發現代應用程序，如跨平臺、Dorker的支持、集成現代前端開發框架(如npm、bower、gulp等等)。另外相比ASP.NET它的性能更好，還內置了依賴注入等功能對開發方式進行了優化。但它們之間也有不少相同或類似的地方，如都使用C#進行開發、都提供了MVC、Entity Framework、Identity等組件來快速構建應用程序。

　　本文將經過遷移一個簡單的ASP.NET應用爲例，來介紹ASP.NET與ASP.NET Core之間的異同，其主要內容有：
　　● .Net Core & ASP.NET Core & .Net Standard
　　● ASP.NET應用遷移分析
　　● 類庫項目遷移
　　　　○ 經過建立新項目完成類庫遷移
　　　　○ 遷移EntityFramework
　　● 遷移ASP.NET MVC
　　　　○ 建立一個新的ASP.NET Core MVC項目
　　　　○ 路由遷移
　　　　○ 過濾器遷移
　　　　○ 依賴注入遷移
　　　　○ Web靜態資源及View遷移
　　● 小結

　　注：本文使用的VS2017爲15.6.4版本，.Net Core SDK版本爲2.1.103。

.Net Core & ASP.NET Core & .Net Standard

　　在介紹如何遷移ASP.NET應用以前，先了解一下新框架.Net Core和ASP.NET Core，.Net Core是一個全新開發平臺，新的運行時、SDK、類庫、工具(編譯工具、項目模板生成工具等等)，而ASP.NET Core則是基於.Net Core的一個Web應用開發框架，它們的關係實際上與.Net Framework和ASP.NET是同樣的。
　　可是在使用.Net開發的時候出現了一個新的名詞.Net Standard，.Net Standard是一個可用於全部.Net程序的API標準，換句話說就是若是使用.Net開發的API(類庫)符合.Net Standard，那麼該類庫將能夠用於全部的.Net應用。以下表所示，若是開發的類庫是以.Net Standard2.0標準開發的，那麼該類庫將可應用到.Net Core2.0、.Net Framework4.6.1(須要.NET Core2.0的SDK支持)、Mono5.四、Xamarin、UWP等平臺的應用上。

　　

　　更多關於.Net Standard的內容可參考文檔：https://docs.microsoft.com/en-us/dotnet/standard/net-standard

ASP.NET應用遷移分析

　　.Net Core雖然是一個全新的開發平臺（新運行時、新SDK、新類庫、新工具），可是它畢竟是以.Net Framework爲基礎，因此對於部分API來講它仍然是參照且兼容.Net Framework的，因此在遷移.Net Core應用時能夠先對代碼進行分析。
　　一、使用工具分析代碼：
　　有一個名爲.Net Portability Analyzer的工具專門用於分析代碼和引用程序集在.Net不一樣平臺上的支持狀況，該工具能夠在VS的拓展管理中搜索並安裝，或者到頁面上下載VS插件雙擊安裝(https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer)：

　　

　　安裝完成後在VS的解決方案窗口中右鍵解決方案或者項目就能夠看到下圖兩個菜單項，分別用於分析程序集的可移植性和對移植分析器的配置：

　　

　　移植分析器的配置主要是對目標平臺和報表輸出類型進行配置：

　　

　　下圖是對My Blog應用進行可移植性分析的Excel報表(部分)：
　　可移植性總結：

　　

　　問題細節：

　　

　　缺失的程序集：

　　

　　注：沒找到更多關於缺乏程序集的解釋，不肯定是沒法解析仍是無兼容性，本文暫時將這些程序集理解爲僅支持.Net Framework平臺。
　　從分析報告中能夠看出，除了MVC項目，其它類庫項目與.Net Core或者.Net standard標準的兼容程度均爲100%。
　　二、根據實際狀況對項目引用進行分析：
　　工具對代碼的分析僅可參考，畢竟使用.Net Framework開發的應用可能引用了不少第三方類庫，這些類庫可能不支持其它平臺，有些類庫可能支持，可是對於原有版本有了不少Break Changes，使用方法與原先不一致了，因此在進行代碼遷移以前對項目引用進行分析，從技術上分析代碼遷移是否可行。
　　本例中倉儲的實現依賴了Entity Framework、EF MySQL、Autofac、Identity等組件，這些組件在.Net Core下也是有相應實現，雖然API會有改動，但技術上是沒有問題的能夠遷移。接下來就開始介紹如何完成遷移。

類庫項目遷移

　　如今.Net Core項目與.Net Framework項目同樣都是使用MSBuild格式的csproj文件來管理項目的相關屬性，如名稱、版本號、包依賴、項目依賴等等，因此實際上項目的遷移最大的改動就是將csproj的內容改成.Net Core的便可(.Net Core的csproj文件詳情參考文檔：https://docs.microsoft.com/en-us/dotnet/core/tools/csproj)，改動csproj文件有兩種方法，若是熟悉文件格式，那麼直接改動原有文件便可，若是不熟悉那麼能夠經過從新建立項目的方式，讓VS來完成建立/修改工做。

經過建立新項目完成類庫遷移

　　本文將經過從新建立項目的方式來完成項目遷移，以保證csproj配置文件的正確性。
　　首先經過VS建立一個.Net Standard的類庫項目：

　　

　　而後把相應的代碼複製到新建項目的目錄下，刪除不存在的命名空間便可。
　　注：.Net Core會自動識別項目目錄下的代碼文件，而原來的.Net Fx項目須要在csporj文件中引入，因此這裏直接複製代碼文件便可識別到項目中。

遷移EntityFramework

　　本例程序中用於實現倉儲的類庫依賴了EF，而實現MySQL EF的類庫還依賴了My SQL的EF相關組件。
另外隨着.Net Core的推出，EF也推出了EFCore，另外新版本的.Net大量引入了Options模式來對程序進行配置，關於Options模式可參考文檔：https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-2.1
　　中文文檔：https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration
　　因此在遷移EF的時候，除了建立新的項目，還須要安裝新的Nuget包而且修改相應的配置代碼：
　　1. 安裝EFCore組件：
　　安裝Microsoft.EntityFrameworkCore：

　　

　　2.處理EFCore的配置：
　　EFCore配置文檔：https://docs.microsoft.com/zh-cn/ef/core/miscellaneous/configuring-dbcontext

　　

　　注：EFCore針對不一樣數據庫的配置信息經過DbContextOptions對象完成，因此構造方法再也不是一個簡單的鏈接字符串，另外EFCore提供了針對ASP.NET Core容器的依賴注入方法，爲了利用依賴注入能夠把DbContext配置交由ASP.NET Core項目完成，包括對不一樣數據源的支持。

　　經過上面的方法便可把例子中的類庫項目完成遷移，接下來進行MVC項目的遷移工做。

遷移ASP.NET MVC

　　ASP.NET Core是一項變革，除了跨平臺以外，它還改變了原先ASP.NET的思想和開發方式，如MVC及API的Controller合二爲1、擁抱現代前端開發方式方法、Dorcker支持等，接下來將經過介紹其遷移過程來了解ASP.NET與ASP.NET Core的異同。

建立一個新的ASP.NET Core MVC項目

　　相對與類庫來講MVC項目的遷移要複雜的多，由於新的ASP.NET在項目文件結構、程序啓動、開發方式等方面都有了區別，這裏仍然使用建立新項目的方式完成ASP.NET MVC應用的遷移：
　　建立一個ASP.NET Core MVC應用：

　　

　　下面是新項目的目錄結構：

　　

　　ASP.NET Core MVC與原先ASP.NET MVC相似核心仍然是Controllers、Models、Views三個目錄，另外經過wwwroot目錄對HTML資源進行了整合、配置文件變動爲Json格式、刪除了Global.asax取而代之的是Program.cs和Startup.cs文件。
　　ASP.NET開發的Web應用程序須要IIS做爲宿主才能夠運行，而ASP.NET Core做爲一種可跨平臺的Web應用開發框架其應用一定是與IIS徹底解耦的，因此它的啓動方式也徹底不同。
　　ASP.NET Core中引入了Program類型，如Console應用同樣經過Main方法來運行程序，而ASP.NET Core的Main方法主要內容是指明一個Startup類型完成Web服務器的建立。而Startup類型則負責了整個應用的配置和HTTP請求管道搭建的任務，因此首先要完成的工做就是將原先Global及Owin Startup文件中的內容移植到Startup文件中，下面就開始詳細介紹ASP.NET Core MVC的變化及遷移方法。
　　MVC除了包含Controller、Model、View等文件外，還須要進行路由、過濾器等功能配置，因此首先須要將原項目的相關文件(controller、model、view等注：由於原項目和ASP.NET Core的MVC都依賴Identity實現用戶管理功能，因此涉及到用戶管理的部分不須要複製)複製到新項目中，修改命名空間引用如：System.Web.Mvc->Microsoft.AspNetCore.Mvc並修復其它命名空間引用錯誤。
　　接下來完成其它幾個重要方面的遷移。

路由遷移

　　將原有的路由配置包含Area的路由配置轉移至Startup類型的Configure方法中：

　　

　　注：本例存在Controller名稱重名狀況，但ASP.NET Core MVC沒有提供如ASP.NET中經過命名空間區別的方式區別Controller重名，本例經過修更名稱解決問題，如需命名空間區分Controller可參考：https://stackoverflow.com/questions/34306891/restrict-route-to-controller-namespace-in-asp-net-core

過濾器遷移

　　全局過濾器的配置則是由原來的經過FilterConfig對象註冊改成Startup的ConfigureServices方法中對MVC進行配置：

　　

　　

依賴注入遷移

　　ASP.NET Core內置了依賴注入功能，甚至一些組件都提供了專門的拓展方法將其服務添加到容器中，如EFCore、Identity、MVC。

　　

　　上圖爲ASP.NET Core默認的爲將DbContext、Identity以及MVC相關服務添加到容器的代碼，除此以外爲了順應依賴注入思想，這裏將原有代碼的倉儲和服務類型均註冊到容器中，其依賴經過構造方法進行注入。
　　倉儲代碼：

　　

　　業務代碼：

　　

　　控制器代碼：

　　

　　服務註冊代碼：

　　

　　注：本例中實現依賴的是實現而非抽象，這不符合依賴倒置原則，因此此處僅做爲ASP.NET Core依賴注入使用示例。另外爲了讓EFCore支持MySQL，因此須要在項目中添加Pomelo.EntityFrameworkCore.MySql組件：

　　

Web靜態資源及View遷移

　　ASP.NET的頁面是基於HTML實現的，一個ASP.NET的頁面除了HTML代碼外還會引用一些外部靜態資源，如css、js、image、font等內容，而ASP.NET中專門提供了Bundle技術來管理這些資源（可參考：《ASP.NET沒有魔法——ASP.NET MVC界面美化及使用Bundle完成靜態資源管理》），那麼ASP.NET Core是如何管理這些資源的呢？
　　首先要處理ASP.NET Core中靜態文件的訪問問題，在ASP.NET中因爲它依賴IIS，而靜態文件訪問已經被IIS處理了，因此程序中無需關心，但ASP.NET Core不同，須要在其請求管道中添加相應的處理中間件：

　　

　　注：ASP.NET Core項目模板默認添加該中間件。
　　對於靜態資源的管理ASP.NET Core經過bundleconfig.json配置文件進行配置取代了原先的BundleConfig類型。把原先的資源文件複製到ASP.NET Core的wwwroot目錄下，而後在bundleconfig.json文件下進行配置，以下圖(部分)：

 　　

　　完成配置後還須要在項目中添加一個BuildBundlerMinifier的組件：

　　

　　引入BuildBundlerMinifier後編譯項目就會觸發資源綁定和最小化操做：

　　

　　注：和ASP.NET不一樣，Core裏面的靜態資源管理是在編譯過程當中處理的，而且經過一個json配置文件完成處理定義，除了BuildBundlerMinifier外還可使用Gulp等工具完成資源的優化，關於Gulp的使用可參考：https://docs.microsoft.com/en-us/aspnet/core/client-side/bundling-and-minification?view=aspnetcore-2.0&tabs=visual-studio%2Caspnetcore2x#consume-bundleconfigjson-from-gulp

　　完成靜態資源遷移後由於Bundle機制的改變還須要對View中資源引用進行修改(ASP.NET Core中再也不提供@Scripts和@Styles類型來渲染樣式和腳本引用)：

　　

　　

　　運行結果：

　　

小結

　　.Net Core是一個新的開發框架，2.0版本的.Net Core已經相對完善，本文介紹了一個簡單的ASP.NET MVC遷移至.Net Core的例子，從例子中能夠看出新的開發平臺已經實現了原有的全部功能和解決方案，甚至在原有基礎上進行了改進。另外.Net Core做爲新框架它是開源的而且相對於.Net Framework來講它的文檔更全面(中文文檔相對落後)，因此.Net Core更容易學習和使用。

　　對於遷移來講，首先仍是看需求和目的，爲何要進行遷移？爲了容器化？跨平臺部署？在真實項目中遷移一個項目是很是複雜且具備風險的，因此若是要進行遷移須要慎重考慮，考慮遷移是不是最好的解決方案。

　　

參考：

　　http://crbtech.in/Dot-Net-Training/9-things-know-converting-asp-dot-net-to-dot-net-core/
　　https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj
　　https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-2.1
　　https://docs.microsoft.com/en-us/aspnet/core/client-side/bundling-and-minification?view=aspnetcore-2.1&tabs=visual-studio%2Caspnetcore2x
　　https://stackoverflow.com/questions/34306891/restrict-route-to-controller-namespace-in-asp-net-core

　　https://docs.microsoft.com/en-us/aspnet/core/migration/proper-to-2x/?view=aspnetcore-2.1

本文連接：http://www.cnblogs.com/selimsong/p/8870286.html