乐趣区

关于.net:NET-生态系统的蜕变之-NET-6

jiezi

.NET 6 是自.NET 4 框架以来生态系统看到的最大版本更新，尽管.NET Core 是 2014 年开始十分大的一项重大策略动作，然而.NET 6 是真正的具备弱小能源的十分重要的版本。

微软 MVP 实验室研究员

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/…


从.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/b…

变化很大

咱们从 .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，热重载 到 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/shany…

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 年的第二个季度正式公布，倡议以后采取张望的办法，进行小的尝试以理解平台在全面采纳之前的长期倒退方向。

微软最有价值专家（MVP）

微软最有价值专家是微软公司授予第三方技术专业人士的一个寰球奖项。28 年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和教训而取得此奖项。

MVP 是通过严格筛选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的激情并乐于助人的专家。MVP 致力于通过演讲、论坛问答、创立网站、撰写博客、分享视频、开源我的项目、组织会议等形式来帮忙别人，并最大水平地帮忙微软技术社区用户应用 Microsoft 技术。
更多详情请登录官方网站：
https://mvp.microsoft.com/zh-cn

这里有更多微软官网学习材料和技术文档，扫码获取免费版！
内容将会不定期更新哦！

退出移动版