.NET 生態系統的蛻變之 .NET 6

.NET 6 是自.NET 4 框架以來生態系統看到的最大版本更新,雖然.NET Core 是2014年開始非常大的一項重大戰略舉措,但是.NET 6是真正的具有強大動力的非常重要的版本。

2021年11月9日即將正式發佈的.NET 6, 也許你認爲.NET 5纔剛剛發佈,我纔剛開始使用.NET Core 3.1, .NET6 就又要發佈了 ,沒錯的,.NET 5是2020年11月10日發佈,.NET Core 3.1早在2019年12月就發佈了,微軟已經承諾了每年都會發佈一個版本的.NET , .NET 6正是按照時間表發佈的版本。和這個版本發佈節奏對應有一個支持政策:https://dotnet.microsoft.com/platform/support/policy/dotnet-core#cadence

image

從.NET 5開始,奇數版本版本18個月修補丁週期,而偶數版本有 三年 的修補丁週期。如果您已經將應用遷移到.NET Core 3.1,請注意,它有一個爲期三年的修補丁週期,將於 2022 年 12 月結束;如果您仍在任何之前版本的 .NET Core上,則您目前已不在支持週期內。雖然尚未宣佈對.NET框架 4.6.2 及以後的支持正式結束,但微軟表示,.NET 框架 4.8 是.NET 框架的最後一個主要版本,將會隨Windows 的支持計劃更新:新的功能開發應針對以前稱爲 .NET Core(例如.NET 6)的平臺。

.NET 6 帶來了許多性能改進和生產力提升,而且還是一個長期支持版本 。在.NET 的每個連續版本中,.NET 在執行速度和內存使用方面都取得了一些令人印象深刻的進步。如果你一直沒有跟蹤, 你很可能會被. NET 框架的累積收益吹走。這一點你可以看看Techempower的測試的報告,具體參見 https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite


變化很大


我們從 .NET 5開始向前看,作爲長期支持 (LTS) 版本,.NET 6 代表着進一步的改進,並具有大量的設計和性能改進。我們將主要看看ASP.NET 6 運行時間的性能改進列表和.NET 6 中的中斷更改,可以看到變化非常大。


C# 語言更新

C#語言的最新版本是10.0,有幾個有趣的變化,對於愛整潔的csharper 來說,全局引用(Global using)和 文件範圍的命名空間 是很好的互補。現在,您可以聲明適用於整個編譯單元(很可能是項目)的全局使用,並避免到每個文件頂部的去添加相同指令集。文件範圍的命名空間還允許您聲明適用於給定文件中所有代碼的命名空間,無需單行無需更多匹配捲曲大括號,源文件中的凹痕級別也較少。

以前

CSharp9_Widget.cs
using System;
using System.Collections.Generic;
using System.Linq;

namespace MyNamespace.Data
{
	class Widget
	{
		private List<WidgetPart> _widgetParts;
		public IEnumerable<WidgetPart> RequiredParts => 
			_widgetParts;

		public bool RequiresPart(int partId) => 
			_widgetParts.Any(x => x.Id == partId);
	}
}
CSharp9_WidgetPartsInventory.cs
using System;
using System.Collections.Generic;
using System.Linq;

namespace MyNamespace.Data
{
	class WidgetPartsInventory
	{
		private Dictionary<int, WidgetPart> _widgetPartsById;

		public bool HavePartsToBuildWidget(Widget widget) => 
			widget.RequiredParts.All(p => 
				_widgetPartsById.ContainsKey(p.Id));
	}
}

現在:

CSharp10_GlobalUsing.cs
global using System;
global using System.Collections.Generic;
global using System.Linq;
CSharp10_Widget.cs
namespace MyNamespace.Data;

class Widget
{
	private List<WidgetPart> _widgetParts;
	public IEnumerable<WidgetPart> RequiredParts => _widgetParts;

	public bool RequiresPart(int partId) => 
		_widgetParts.Any(x => x.Id == partId);
}
CSharp10_WidgetPartsInventory.cs
namespace MyNamespace.Data;

class WidgetPartsInventory
{
	private Dictionary<int, WidgetPart> _widgetPartsById;

	public bool HavePartsToBuildWidget(Widget widget) => 
		widget.RequiredParts.All(p => 
			_widgetPartsById.ContainsKey(p.Id));
}

還有其他一些與Record、模式和插值字符串相關的更新,但這些更新大多是語法糖。


ASP.NET Core 更新


如果你閱讀每個版本的說明,很容易看到 ASP.NET Core 是一個核心,從網絡主機和最小 API,熱重載 到blazor都有很多感興趣特性。

網絡主機和最小 API

從 ASP.NET Core開始,每個應用程序都將應用初始化代碼拆分爲Program.cs(用於創建 Web 主機)和"Startup.cs(用於配置路由和 IoC 容器配置等應用程序問題)中,通常包含的兩個單獨的Class。特別是Startup類有一種神奇的感覺,它的方法從來沒有被開發人員直接調用。而是WebHost在幕後自動調用配置方法。

ASP.NET團隊分析了這個設計,並與其他 Web 框架相比,認爲設置涉及的東西太多。因此,最小的API概念誕生了。 現在,應用程序初始化可以全部包含在一個文件中。而且你可能感到奇怪,Main方法都不需要了。可以在應用設置中定義路由,從而大大減少代碼數量以啓動和運行一個應用程序。

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

當然如果你仍然喜歡將服務設置與應用配置分離的組織樣式,你仍然可以爲 IServiceCollection 和 IApplicationBuilder 創建擴展方法,並從構建器和應用程序對象調用它們。


Hot Reload

幾年來,許多 Javascript 框架都支持熱重載,現在它也成爲 C#中 ASP.NET Core應用的標配:通過熱重加載,您可以在應用運行期間(在調試器下)編輯您的 C#代碼,並且您的代碼更改將自動反映在您的應用中,而不會丟失應用狀態。換句話說,應用程序不需要重新啓動。對於調試和交互式開發工作流程來說,這應該是一個很好的改進。 這個功能對於開發來說非常重要,就是這個小功能微軟近日激怒了開源.NET社區,好消息是微軟聽取了社區的聲音,恢復了通過CLI支持HotReload功能。具體參見 https://www.cnblogs.com/shanyou/p/15450214.html


Blazor

在 ASP.NET Core 6 裏面有大量的更新是關於Blazor。例如,Blazor 應用程序現在可以直接編譯到 WebAssembly,以便在 IL 解釋(即.NET 本地編譯)版本的相同代碼上來提高應用程序速度。本地編譯/調試體驗仍然很快,因爲漫長的編譯時間僅適用於包裝/發佈。說到性能,Blazor WebAssembly可實現客戶端代碼的多線程。Javascript 受制於瀏覽器中的單線程。真正的多線程爲可以從並行處理中受益的應用程序開闢了一些新的可能性(當然,這取決於瀏覽器的支持)。

還有一個非常有趣的功能,使 Blazor 可用於通過 MAUI 編寫桌面應用程序。 Blazor 的最大好處就是開發人員可以完全用 C# 編寫 Web 應用程序,而不需要爲了寫前端必須切換到 Javascript。 如果沒有 C# 和 Javascript 之間的額外接縫,前端和後端代碼之間就不需要映射層。 可以在兩側使用相同的 C# 模型,這意味着需要的代碼更少,因此開發應用程序所需的時間也更少。 Blazor 桌面進一步擴展了這一概念,以允許此共享代碼現在也可以與桌面應用程序無縫集成。


MAUI

MAUI 是 Multi-platform App UI 的縮寫,是微軟對跨平臺 UI 框架的下一個嘗試。 MAUI 是 Xamarin 的演進,還包括桌面平臺。 它允許從單個代碼庫針對 iOS、Android、macOS 和 Windows。 MAUI 處理對本機平臺 API 的抽象,因此您可以以與平臺無關的方式訪問設備傳感器等內容。 對 Xamarin 的一種印象是,它們最終得到的界面很少,而且在任何平臺上都不太好看。 MAUI 將如何解決這一問題還有待觀察。 如果你關心的是跨多個平臺的開發速度和維護成本,那麼 MAUI 值得仔細研究。 MAUI 要在2022年的第二個季度正式發佈,建議當前採取觀望的方法,進行小的嘗試以瞭解平臺在全面採用之前的長期發展方向。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章