為什麼選擇.NETCore?
為什麼選擇.NETCore?
學習新的開發框架是一項巨大的投資。您需要學習如何在新框架中編寫,構建,測試,部署和維護應用程式。作為開發人員,有許多框架可供選擇,很難知道什麼是最適合的。即使您正在使用.NET開發軟體,.NET Core也不相同,您需要花時間學習使用它的工具和技術。為了理解為什麼.NET Core值得一看,這有助於知道你從哪裡開始。
.NETCore的開源協議
.NET Core從屬於.NET基金會,由微軟進行官方支援。使用最寬鬆的MIT和Apache 2開源協議,文件協議遵循CC-BY。這將允許任何人任何組織和企業任意處置,包括使用,複製,修改,合併,發表,分發,再授權,或者銷售。唯一的限制是,軟體中必須包含上述版 權和許可提示,後者協議將會除了為使用者提供版權許可之外,還有專利許可,並且授權是免費,無排他性的(任何個人和企業都能獲得授權)並且永久不可撤銷,相較於oracle對java和mysql的開源協議微軟做出了最大的誠意
如果您是.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作為一個整體產品釋出,但是.NETCore被分解成多個部分。現在開發人員可以選擇使用哪個版本的庫。只要它在.NET標準庫之外,.NET Core團隊就可以用較少的難度進行創新。這就是為什麼在將來你只能看到錯誤修復的框架; .net core將獲得所有新功能。
釋出週期更快
如果您曾在框架中遇到錯誤,並將其報告給Microsoft,則您將知道釋出修復需要多長時間。這個框架有很長的釋出週期,通常至少要測量一年,而且在這些週期中還有很小的視窗用於特性工作。每個程式碼更改都可能會導致框架中其他位置出現意外的問題。為了給每個團隊足夠的時間來測試框架,有很多時候程式碼更改是受限制的或者嚴格審查的。如果您在.NET中發現了一個錯誤,最好找到一個解決方法,而不是等待更新(這也是.NETCore開源帶來的好處,您不需要完全依賴微軟支援才能解決問題,這對於大型企業更是有利,可以利用技術資源來對.NETCore進行本企業定製化,成為.NETCore的分支來執行)。
.NET Core遵循更快的釋出步調。開發人員可以使用夜間構建來儘早測試。不屬於.NET標準庫的庫可以按自己的步調發布。因為所有東西都是開源的,如果微軟沒有足夠快的響應,任何開發者都可以提出修補。如果解決方法不被接受,討論就會公開進行,所有人都可以看到為什麼做出這個決定
如果你是.NET新手
在Windows平臺上,.NET框架沒有太多的競爭。微軟可以對從作業系統核心層到高階.NET庫的所有內容進行更改。通過將.NET引入其他平臺,競爭環境發生了變化。.NET現在必須與其他所有的開發框架競爭。
C#是一個了不起的語言
.NET的旗艦語言C#具有許多獨特的功能,例如語言整合查詢和非同步構造,這使得它強大且易於使用。相較於保守的java(我們也看到Oracle旗下的老牌java已經已經越來越難推出新特性,這是歷史包袱所導致,在將來模組化的開發中很難進行更新維護)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實現共享相同的庫。
metzgar_whynetcore_01
圖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標準庫編寫應用程式或庫。
然後它可以在許多平臺上共享。
metzgar_whynetcore_02
圖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萬個。
metzgar_whynetcore_03
圖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作為複雜web開發的效能已經相較於之前有質的提高, ASP.NET Core VS node.js
ASP.NET Core表明了微軟思維的轉變。微軟意識到它必須具有競爭力才能贏得開發者。它還必須在Windows以外的平臺上競爭。這是建立.NET Core的原動力。
開源
現代軟體開發人員並不滿足於尋求功能。當已經有一個滿足他們需求的開源專案的時候,尤其如此。當大公司熱衷於開源軟體時,即使是最忠實的微軟開發者也會轉向其他框架和庫,以便在預算內按時完成自己的專案。如果微軟關心“開發人員,他們必須做出改變。
公開.NET Framework的原始碼是第一步。.NET Framework原始碼已經在referencesource.microsoft.com 和GitHub上公開了好幾年了。
metzgar_whynetcore_04
圖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是否支援型別,方法,屬性等。
metzgar_whynetcore_05
圖5 Visual Studio IntelliSense指示.NET Core中是否有類或成員可用
。NET可移植性分析器
如果您試圖將現有的.NET應用程式轉換為.NET Core,那麼最好的地方就是.NET可移植性分析器。它既可以作為命令列應用程式,也可以作為Visual Studio外掛使用。有許多.NET平臺可供選擇:
metzgar_whynetcore_06
圖6 .NET可移植性分析器中提供的目標平臺
儘可能使用此工具建立一個詳細的報告,提供有用的建議:
metzgar_whynetcore_07
圖7。.NET可移植性分析器報告
反射
.NET Core中的反射工作方式與.NET Framework中的不同。最明顯的區別是,Type類上正常的許多操作不再存在。有些人已經被調到一個新的TypeInfo類。其他操作在.NET標準庫中不可用,並且需要額外的依賴性。
.NET Framework實現反射
複製程式碼
.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框架已經到了不得不做出改變的時候,以跟上競爭對手。.NETCore是.NET演進過程中必不可少的一步。它將最好的.NET Framework與現代軟體開發中使用的實踐相結合。諸如可移植性,簡單部署,高效能,開放原始碼和強大支援等特性使其值得一試。
Why Choose .NET Core?
相關文章
- 為什麼選擇Guice框架GUI框架
- 為什麼選擇使用Rust?Rust
- Aembit為什麼選擇 Rust?Rust
- 為什麼選擇Cynefin框架? – zwischenzugs框架
- 為什麼選擇高防DNS?DNS
- 為什麼選擇centos系統CentOS
- 為什麼選擇Python做爬蟲Python爬蟲
- 為什麼選擇ASP.NET CoreASP.NET
- 為什麼建議新手選擇Ubuntu?告訴你選擇理由!Ubuntu
- 阿里巴巴為什麼選擇Apache Flink?阿里Apache
- 為什麼選擇獨立伺服器伺服器
- [20200326]為什麼選擇這個索引.txt索引
- 你當初為什麼選擇了前端?前端
- 為什麼選擇無伺服器模型?伺服器模型
- 為什麼爬蟲要選擇住宅代理?爬蟲
- 老闆:你為什麼要選擇 Vue?Vue
- Elasticsearch 中為什麼選擇倒排索引而不選擇 B 樹索引Elasticsearch索引
- 什麼Jupyter?為什麼初學Python推薦選擇Jupyter?Python
- 新加坡為什麼是ICO的最後選擇,同時也是最佳選擇?
- 我為什麼放棄MySQL?選擇了MongoDBMySqlMongoDB
- 大公司為什麼要會選擇DevOps?dev
- 為什麼要選擇Apache Pulsar:IO隔離Apache
- (轉)為什麼選擇機器學習策略機器學習
- 為什麼選擇Java?Java具體好在哪?Java
- 為什麼要選擇代理來進行抓取?
- 為什麼要選擇分散式資料庫?分散式資料庫
- 為什麼選擇高防DNS雲解析?(一)DNS
- 為什麼要選擇電話機器人?機器人
- 為什麼伺服器選擇Linux系統伺服器Linux
- 為什麼選擇學習六西格瑪?
- 為什麼選擇 Intellij IDEA 作為日常開發工具IntelliJIdea
- 我為什麼選擇成為獨立開發者
- 你是怎麼選擇resetting和normalizing的?為什麼?ORM
- 為什麼我會選擇走 Java 這條路?Java
- 為什麼要選擇蘋果企業簽名?蘋果
- 為什麼Dark不選擇Rust/Clojure/Haskell/Scala? - darklangRustHaskell
- 為什麼不上架,選擇企業簽名?
- 為什麼你應當選擇 PostgreSQL 而不是 Oracle?SQLOracle