为什么选择.NETCore？
?為什么選擇.NETCore？
在開展話題之前先出一張ASP.NETCore VS? Node.js的性能對比圖??ASP.NET Core? VS? node.js：
繼續正文：
學習新的開發框架是一項巨大的投資。您需要學習如何在新框架中編寫，構建，測試，部署和維護應用程序。作為開發人員，有許多框架可供選擇，很難知道什么是最適合的。即使您正在使用.NET開發軟件，.NET Core也不相同，您需要花時間學習使用它的工具和技術。為了理解為什么.NET Core值得一看，這有助于知道你從哪里開始。
如果您是.NET Framework開發人員
.NET Core是為了重新啟動某些Framework組件而為其他人提供跨平臺工作的機會。由于.NET Framework主要以托管（C＃）代碼為基礎構建，因此這些部分不需要更改代碼即可移至.NET Core。依賴于Windows特定組件的庫必須被移除或重構以使用跨平臺替代方案。這同樣適用于您的應用程序。
您的.NET應用程序可以是跨平臺的
您現有的.NET Framework應用程序可以在其他操作系統上工作。對于希望擴大類庫的受眾平臺，或者希望在分布式應用程序的其他領域使用相同代碼的開發人員來說，這是非常好的選擇。即使你想用你亮瞎眼的MacBook上開發.NET，而無需雙啟動到Windows。
并不是所有的框架都被移植到.NET Core，但主要的部分。存在一些API差異。例如，如果您使用了大量的反射，則可能需要重構代碼才能使用Core。有關更多信息，請看文章末尾的的兩者差異部分。
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 inowningElement.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框架已經到了逼到不得不做出改變的時候，以跟上競爭對手。.NETCore是.NET演進過程中必不可少的一步。它將最好的.NET Framework與現代軟件開發中使用的實踐相結合。諸如可移植性，簡單部署，高性能，開放源代碼和強大支持等特性使其值得一試。
Why Choose .NET Core?
原文地址:https://www.cnblogs.com/xiaoliangge/p/8373100.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的为什么选择.NETCore？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微软Azure AspNetCore微服
- 下一篇： AWS Lambda现已支持.NET C