為什麽選擇.NETCore？

學習新的開發框架是一項巨大的投資。您需要學習如何在新框架中編寫，構建，測試，部署和維護應用程序。作為開發人員，有許多框架可供選擇，很難知道什麽是最適合的工作。即使您正在使用.NET開發軟件，.NET Core也不相同，您需要花時間學習使用它的工具和技術。為了理解為什麽.NET Core值得一看，這有助於知道你從哪裏開始。

如果您是.NET Framework開發人員

.NET Core是為了重新啟動某些Framework組件而為其他人提供跨平臺工作的機會。由於.NET Framework主要以托管（C＃）代碼為基礎構建，因此這些部分不需要更改代碼即可移至.NET Core。

您的.NET應用程序可以是跨平臺的

您現有的.NET Framework應用程序可以在其他操作系統上工作。對於希望擴大受眾的圖書館作者，或者希望在分布式應用程序的其他領域使用相同代碼的開發人員來說，這是非常好的選擇。即使你想用你的閃亮新MacBook上的.NET開發，而無需雙啟動到Windows。

並不是所有的框架都被移植到.NET Core，但主要的部分。存在一些API差異。例如，如果您使用了大量的反射，則可能需要重構代碼才能使用Core。有關更多信息，請參閱下面的“與.NET Framework的差異”一節。

ASP.NETCore勝過框架ASP.NET

ASP.NET Core和ASP.NET之間的性能差異是幾個數量級。大部分的ASP.NET被傳統的System.Web庫所限制。.NET Framework支持舊版本的ASP.NET項目，而且這個約束限制了ASP.NET的發展。微軟決定重寫整個堆棧。這意味著打破變化，但收益值得遷徙。

.NETCore是創新的焦點

向後兼容性是一把雙刃劍。這意味著您的應用程序可以繼續得到新版本框架的支持，這是一個流行的功能。確保在新版本框架中所做的更改不會破壞現有的應用程序。這不是百分之百的情況，但是很接近。

所有的努力避免變化都限制了框架的創新。

使用.NET Core，團隊可以更容易專註的在.net core上工作。比如核心類庫（如System.Collections）的更改仍然需要與.NET Framework相同的活力，但是ASP.NET Core或Entity Framework Core可以更輕松地進行實質性更改，而不受向後兼容性的限制。這允許更大的創新。

.NET Framework作為一個整體產品出貨，但是Core被分解成多個部分。現在開發人員可以選擇使用哪個版本的庫，只要它在.NET標準庫之外，.NET Core團隊就可以用較少的難度進行創新。這就是為什麽在將來你只能看到錯誤修復的框架; .net core將獲得所有新功能。

發布周期更快

如果您曾在框架中遇到錯誤，並將其報告給Microsoft，則您將知道發布修復需要多長時間。這個框架有很長的發布周期，通常至少要測量一年，而且在這些周期中還有很小的窗口用於特性工作。每個代碼更改都可能會導致框架中其他位置出現意外的問題。為了給每個團隊足夠的時間來測試框架，有很多時候代碼更改是受限制的或者嚴格審查的。如果您在.NET中發現了一個錯誤，最好找到一個解決方法，而不是等待更新。

.NET Core遵循更快的發布步調。開發人員可以使用夜間構建來盡早測試。不屬於.NET標準庫的庫可以按自己的步調發布。因為所有東西都是開源的，如果微軟沒有足夠快的響應，任何開發者都可以提出修補。如果解決方法不被接受，討論就會公開進行，所有人都可以看到為什麽做出這個決定

如果你是.NET新手

在Windows平臺上，.NET框架沒有太多的競爭。微軟可以對從操作系統內核層到高級.NET庫的所有內容進行更改。通過將.NET引入其他平臺，競爭環境發生了變化。.NET現在必須與其他所有的開發框架競爭。這裏有一些東西，使.NET分開。

C＃是一個了不起的語言

.NET的旗艦語言C＃具有許多獨特的功能，例如語言集成查詢和異步構造，這使得它強大且易於使用。C＃也在不斷創新。C＃團隊公開設計語言，因為他們希望任何人提出建議或參與討論。編譯器（Roslyn）完全是模塊化和可擴展的。

ASP.NET Core性能與頂級Web平臺相當

如果您正在編寫Web應用程序或服務，那麽ASP.NET Core是一個很好的搭建平臺。它具有出色的性能和低內存占用。許多功能可以使您的應用程序更容易開發和維護。

.NET Core不是從頭開始的

.NET在2000年以前就已經出現了。框架代碼在過去幾年中已經得到了鞏固，開發人員也從中受益。已經被移植到Core的大部分Framework代碼都沒有改變。這使.NET Core在構建應用程序的可靠框架方面領先一步。.NET Core也完全由Microsoft支持。支持可能會阻礙一些組織采用開源軟件。這降低了為您的應用程序使用Core的風險。

什麽是.NETCore？

為了理解.NET Core，它有助於理解.NET Framework。微軟在21世紀初發布了.NET Framework。.NET Framework是一個僅限於Windows的開發框架，它在最底層提供了內存管理，安全性，異常處理和許多其他功能。.NET框架附帶一大堆庫，可執行從XML解析到HTTP請求的各種功能。它還支持幾種語言，並將它們編譯成相同的通用中間語言; 任何語言都可以使用任何其他語言構建的庫。這些關鍵概念也出現在.NET Core中。

2016年，微軟收購了Xamarin並發布了.NET Core 1.0。之前Xamarin已經移植了.NET框架的大部分內容來運行在基於Linux / Unix的操作系統上。一些代碼可以在.NET Framework，Xamarin和新的.NET Core之間共享，但編譯後的二進制文件不能。.NET Core的一部分努力是創建一個標準化的平臺，允許所有.NET實現共享相同的庫。

圖1 .NET框架，.NET Core和Xamarin都共享一個稱為.NET標準庫的標準化平臺

以前的Xamarin和.NET Framework之間是無法共享二進制文件的。隨著.NET標準庫和通用基礎架構的推出，這兩個框架現在成為統一的.NET生態系統的一部分。

什麽是.NETCore？在上圖中，似乎.NET Core是另一個包含UWP（通用Windows平臺）和ASP.NET Core的框架。為了使.NET Core成為現實，創建了.NET標準庫和通用基礎架構。

關鍵的.NETCore功能

.NET Core借鑒了.NET Framework的最佳實踐，並將軟件工程的最新進展結合在一起。這些是.NET Core的一些顯著特征。

擴大您類庫的覆蓋面

使用.NET Core，您可以使用.NET標準庫編寫應用程序或庫。

然後它可以在許多平臺上共享。

圖2 .NETCore開發

同一個庫可以在後臺服務“本地”或雲中運行，也可以在手機，平板電腦或桌面上運行的客戶端應用程序中運行。與其為iOS，Android和Windows構建單獨的應用程序，您可以構建一個適用於所有平臺的應用程序。.NET Core是小型和完美的容器，可以輕松擴展並縮短開發時間。

.NET Core和.NET Standard Library建立了一個通用平臺。過去，當新版本的操作系統或新設備出現時，開發人員有責任重新構建新平臺的應用程序或庫，並分發更新。使用.NET Core，不需要重建和重新分配。只要新的平臺支持你所有的依賴庫，它就支持你的應用程序。

在任何平臺上簡單部署

Microsoft產品往往具有復雜的安裝過程。COM組件，註冊表項，特殊文件夾，GAC - 都是為了利用Windows的特性而設計的。.NET框架依賴於這些構造，這使得它不適合其他操作系統。

在發布依賴於.NET Framework的應用程序時，安裝程??序必須足夠聰明才能檢測是否安裝了錯誤的.NET Framework版本，並為用戶提供正確的方法。大多數現代Windows版本都包含.NET Framework。這使得某些應用程序更容易安裝，但是如果應用程序使用默認情況下未安裝的功能（如ASP.NET與IIS或WCF組件的集成），則可能會導致復雜的問題。

另一個復雜的問題來自補丁。包括錯誤修復或安全更新的修補程序可以通過Windows更新或通過Microsoft下載中心分發給客戶。您測試應用程序的.NET Framework可能與客戶使用的補丁程序不同。當您假定.NET Framework對於所有客戶都是一樣的時候，通常很難確定在應用程序中導致奇怪行為的原因。

.NET Core的模塊化設計意味著您只包含所需的依賴關系。所有這些依賴關系與您的應用程序進入相同的文件夾。部署應用程序與復制文件夾一樣簡單。這種方法的另一個優點是可以有多個版本並行運行。這個策略對於使所有平臺的部署體驗保持一致至關重要。

雲和容器

在雲系統中，用更少的硬件為更高密度的用戶提供服務是非常重要的。應用程序的占位面積越小，密度越高。虛擬機已經在雲端普遍存在多年，但是它們有幾個問題：

• 大小 - 一個典型的虛擬機文件是千兆字節，如果不是幾十千兆字節。這使得它們跨網絡傳輸非常耗時，並且對磁盤空間有很大的要求。
• 啟動時間 - 啟動虛擬機意味著啟動操作系統。對於Windows來說，這是一個挑戰，因為啟動新機器需要花費時間。這可以使處理突發交通困難。
• 內存 - 虛擬機需要將整個操作系統與應用程序一起加載到內存中。這意味著很多主機的內存被浪費了。
• 不一致性 - 相同的虛擬機可以復制到多個主機，主機必須提供相同的虛擬化硬件，這可能依賴於物理硬件。無法保證虛擬機在任何給定的主機上運行相同的操作。

容器通過虛擬化操作系統來解決虛擬機的問題。容器只包含應用程序及其依賴項。文件大小要小很多倍，啟動時間以秒為單位，只有應用程序加載到內存中，容器保證在任何主機上工作。

內置於Windows的.NET Framework不能在容器上運行。鑒於容器的明顯優勢，.NET Core的設計決定之一就是使其成為模塊化。這意味著你的.NETCore應用程序可以被“發布”，使得它和它的所有依賴關系在一個地方，這很容易放入容器。

ASP.NET性能

如果您不熟悉ASP.NET，則是.NET Framework中內置的Web應用程序平臺。ASP.NET被許多有影響力的組織所使用，包括Stack Overflow。ASP.NET是2002年發布的第一個.NET Framework版本，並不斷發展。盡管ASP.NET取得了成功，但在ASP.NET團隊中卻感覺到他們正在失去開發人員，因為ASP.NET的性能沒有競爭力，只能在Windows平臺上運行。

一家名為TechEmpower的公司每隔幾個月就會運行一次Web應用程序平臺的基準測試，並提供一個分為幾類的排名。基準測試在Linux上運行，僅包含Windows平臺。對於ASP.NET團隊來說，這很麻煩。許多平臺都用於編寫跨平臺的Web應用程序，並且其性能數據令人印象深刻。此外，一些Java框架發布了天文數字，例如每秒570萬個明文請求，或者490萬個。

圖3 TechEmpower基準，第12輪

在TechEmpower基準測試的第十一輪中，Mono平臺上的ASP.NET MVC被納入測試。結果不好。Mono上的ASP.NET每秒產生一個微小的2000個明文請求。Mono不是由Microsoft創建的，它不會像普通的.NET Framework那樣得到相同數量的性能調整。為了獲得更公平的比較，ASP.NET團隊決定在與TechEmpower相同的硬件上運行.NET 4.6的基準測試。結果是每秒約50,000個請求。仍然沒有接近NodeJS（每秒320,000個請求），或TechEmpower列表上的其他任何頂級框架。

可憐的低分並不意外。如前所述，ASP.NET知道改變現狀只能通過重寫整個架構來清除障礙。這正是發生的事情。

ASP.NET團隊著手構建ASP.NET Core，幾個月後，該團隊慶祝asp.net core每秒超過100萬個請求。最新asp.netcore與node.js的性能對比更是讓asp.net core的性能優勢繼續擴大

ASP.NET Core VS Node.js

上圖中可看出asp.net core的性能優勢已經超過node.js數倍，性能對比鏈接==> ASP.NET Core VS node.js

ASP.NET Core表明了微軟思維的轉變。微軟意識到它必須具有競爭力才能贏得開發者。它還必須在Windows以外的平臺上競爭。這是創建.NET Core的原動力。

開源

現代軟件開發人員並不滿足於尋求功能。當已經有一個滿足他們需求的開源項目的時候，尤其如此。當大公司熱衷於開源軟件時，即使是最忠實的微軟開發者也會轉向其他框架和庫，以便在預算內按時完成自己的項目。如果微軟關心“開發人員，開發人員，開發人員”，他們必須做出改變。

公開.NET Framework的源代碼是第一步。.NET Framework源代碼已經在參考文獻source.microsoft.com和GitHub上公開了好幾年了。

圖4 .NET Framework參考源

從揭露來源到接受外來的貢獻是完全不同的。.NET Core開發人員不僅希望獲得外部貢獻，還希望將社區納入設計和開發。這導致了更多的透明度。ASP.NET Core團隊每周都會在http：// live.asp.net上舉行一次社區直播會議。.NET Core的代碼從一開始就在GitHub上公開，任何人都可以提出請求。社區成員可以在GitHub中創建錯誤和功能請求。.NET Core已經標誌著微軟在開源方面的重大轉變。

與.NET Framework的差異

.NET Core不僅是Linux和Mac的.NET Framework。微軟並沒有移植所有的.NET Framework，而是采取了等待客戶想要的方式。必須有足夠的客戶對框架功能的興趣來說服微軟分配資源來做端口。移植的障礙之一是最初建立這些功能的團隊大部分已經移動。幸運的是，對於ASP.NET客戶來說，ASP.NET團隊是.NET Core的驅動因素。MVC，Web API和SignalR都可以在.NET Core中找到，或者在路線圖上。

框架功能沒有移植到.NETCore

我給這個列表提供了可以改變的知識。某些功能不適用於非Windows平臺，其他功能將不會由Microsoft推向未來，因為有更好的替換或功能在某些方面有問題（不安全，難以維護等）。 ）。

• WPF / XAML - Windows Presentation Foundation僅適用於用戶界面。.NET標準庫不包括用戶界面庫，.NET Core不會提供跨平臺的UI框架。這意味著像Windows窗體和系統的東西。繪圖不會移植到.NET Core。
• 事務 - 這個庫使創建分布式事務變得容易。它依賴於特定於Windows的組件，使其不易移植到.NET Core。
• AppDomains - 這些對於隔離程序集來說是非常有用的，而且不會終止進程，這對於允許插件的應用程序來說非常有用。它們依賴於某些Windows特定的構造，這些構造在其他操作系統上不起作用。
• .NET遠程處理 - 遠程對象已被REST服務成功。
• ASMX - 編寫已被Web API取代的Web服務的舊方法。
• Linq to SQL - 由實體框架取代。
• WCF服務 - Windows Communication Foundation客戶端功能在.NET Core中可用，但不能創建服務。
• WF - Windows Workflow Foundation依賴於XAML，WCF服務以及其他.NET Framework特性之間的事務。

.NET Framework開發人員的微妙變化

有經驗的.NET Framework開發人員可能會在.NET Core中遇到一些驚喜。編寫新的代碼應該是相對直接的，因為你不太可能使用像HashTableor 這樣的舊的結構ArrayList。Visual Studio的Intellisense也指出.NET Core是否支持類型，方法，屬性等。

圖5 Visual Studio IntelliSense指示.NET Core中是否有類或成員可用

。NET可移植性分析器

如果您試圖將現有的.NET應用程序轉換為.NET Core，那麽最好的地方就是.NET可移植性分析器。它既可以作為命令行應用程序，也可以作為Visual Studio插件使用。有許多.NET平臺可供選擇：

圖6 .NET可移植性分析器中提供的目標平臺

盡可能使用此工具創建一個詳細的報告，提供有用的建議：

圖7。.NET可移植性分析器報告

反射

.NET Core中的反射工作方式與.NET Framework中的不同。最明顯的區別是，Type班上正常的許多操作不再存在。有些人已經被調到一個新的班級TypeInfo。其他操作在.NET標準庫中不可用，並且需要額外的依賴性。

.NET Framework實現反射

PropertyInfo targetProperty = null;
foreach (var property in
         owningElement.GetType().GetProperties())
{
    if (property.Name == this.Name
        && property.PropertyType.IsGenericType)
    {

The .NET Core 實現反射.

PropertyInfo targetProperty = null;
foreach (var property in
owningElement.GetType().GetProperties()) 
{
if (property.Name == this.Name && property.PropertyType
.GetTypeInfo().IsGenericType)           
{

?需要依賴於System.Reflection.TypeExtensions

? 許多類型操作移到了TypeInfo

概要

軟件開發行業正在不斷發展。從語言到框架，工具到方法論，一切都受到挑戰和改進。.NET框架已經到了b不得不做出改變的時候，以跟上競爭對手。.NETCore是.NET演進過程中必不可少的一步。它將最好的.NET Framework與現代軟件開發中使用的實踐相結合。諸如可移植性，簡單部署，高性能，開放源代碼和強大支持等特性使其值得一試。

為什麽選擇.NETCore？