|
前些时候，.NET Core团队宣布了.NET Core的下一个版本2.1的发展蓝图。以下是Daniel Roth通过Blog发布的详细计划。 下面概述了本次发布计划的功能和改进，目标是2018年中期。 Razor页面的改进 在ASP.NET Core 2.0中，我们引入了Razor Pages作为构建Web UI的新分页模型。在2.1中，我们正在对Razor Pages进行各种改进，使其更加高效。 剃刀页面在一个地区 区域提供了一种将大型MVC应用程序划分成更小的功能组的方法，每个功能组都有自己的控制器和视图。在2.1中，我们将增加对Razor Pages的支持，以便区域可以有自己的页面目录。 支持/ Pages / Shared 在2.1 Razor页面将回落到寻找Razor资产，如布局和部分在/ [页面根目录] /共享之前，回落到/ Views / Shared。除此之外，页面本身现在可以在/ [页面根目录] /共享路径中，并且它们将可路由，就好像它们直接存在于/ [页面根] /，除非页面实际上存在于该位置，在这种情况下它将被代替。 绑定页面或控制器上的所有属性 从2.0开始，您可以使用BindPropertyAttribute来指定页面模型或控制器上的属性应该绑定到请求中的数据。如果你有很多你想要绑定的属性，那么这会变得单调乏味。在2.1中，我们将添加支持，指定页面或控制器上的所有属性应该通过将BindPropertyAttribute放在类上进行绑定。 在页面模型上实现IPageFilter 我们将在页面模型上实现IPageFilter，以便您可以在页面处理程序针对给定请求运行之前或之后运行逻辑，这与您可以在控制器上实现IActionFilter的方式大致相同。 功能测试基础架构 编写MVC应用程序的功能测试允许您测试端到端请求的处理，包括运行路由，筛选器，控制器，操作，视图和页面。在ASP.NET Core 2.0中，为MVC应用程序编写内存中功能测试是可能的，但它需要大量的设置。 对于2.1，我们将提供一个测试夹具实现来处理使用TestServer测试MVC应用程序时的典型缺陷：
Web API改进 ASP.NET Core为您提供了一个用于构建Web UI和Web API的单一统一框架。在2.1中，我们正在对构建Web API的框架进行各种改进。 更好的输入处理 我们希望围绕无效输入的体验更自动，更一致。更具体地说，我们将要：
支持问题细节 我们正在增加对RFC 7808的支持 - HTTP API的问题详细信息，作为返回HTTP API的机器可读错误响应的标准化格式。您可以使用ValidationProblem（）辅助方法从API操作返回Problem Details响应。 改进的OpenAPI规范支持 我们希望接受OpenAPI规范（以前称为“Swagger”），并使用ASP.NET Core构建的Web API更具描述性。今天，你需要大量的“属性汤”才能从ASP.NET Core获得合理的OpenAPI规范。我们计划引入一个自发的图层，根据您的行为可能会做出的回应来推断可能的回应（属性在您想要显式时仍然会获胜）。 增强的Web API控制器约定和ActionResult 我们添加了[ApiController]属性作为选择加入Web API特定约定和行为的方式。这些行为包括：
JSON补丁的改进 对于JSON补丁，我们将添加对测试操作符的支持以及用非字符串键修补字典。 部分标签助手 剃刀局部视图是将剃刀内容包含到视图或页面中的一种便捷方式。今天有四种不同的方法可以在页面上呈现不同的权衡和限制（Html.Partial vs Html.RenderPartial，sync vs async）。渲染partials也受到限制，其中基于给定模型的渲染表单元素的生成前缀必须为每个局部渲染手动处理。 Razor UI在类库中 ASP.NET Core 2.1将使构建和在一个库中包含基于Razor的用户界面变得更加容易，并将其分享到多个项目中。一个新的Razor SDK可以将Razor文件构建到一个类库项目中，然后将其打包成一个NuGet包。库中的视图和页面将被自动发现，并可被应用程序覆盖。通过将Razor编译集成到构建中，应用程序启动时间也显着加快，同时仍允许在运行时快速更新Razor视图和页面，这是迭代开发工作流的一部分。 SignalR 对于ASP.NET Core 2.1，我们将ASP.NET SignalR移植到ASP.NET Core以支持实时Web方案。如前所述，ASP.NET Core SignalR还将包括一些改进，包括简化的横向扩展模型，没有jQuery依赖的新的JavaScript客户端，基于MessagePack的新的紧凑二进制协议，支持自定义协议，新流式响应模型以及基于裸WebSockets的客户端支持。您可以通过检查样本来开始尝试ASP.NET Core SignalR。 网络挂接 WebHooks是一个轻量级的HTTP模式，用于通过网络进行事件通知。WebHooks使服务能够通过HTTP向注册用户发送事件通知。对于2.1，我们将ASP.NET WebHooks接收器的一个子集以一种与ASP.NET Core成语集成的方式移植到ASP.NET Core。 对于2.1，我们计划移植下列接收器： Microsoft Azure警报 微软Azure Kudu通知 Microsoft Dynamics CRM 到位桶 Dropbox的 GitHub上 MailChimp 推 销售队伍 松弛 条纹 Trello WordPress的 GDPR的改善 ASP.NET Core 2.1项目模板将包含一些扩展点，以帮助您满足您的一些通用数据保护法规（GDPR）要求。 新的Cookie同意功能将允许您请求（并跟踪）用户同意存储个人信息。这可以结合一个新的cookie功能，其中cookie可以被标记为基本或非必要的。如果用户不同意数据收集，非必要的cookies不会被发送到浏览器。您仍然需要在用户界面提示符和适当的隐私政策上创建符合您或贵公司所执行的GDPR分析的措辞，同时实施确定在什么条件下给定用户应先征得同意书的逻辑 - 基本cookie（模板只是默认为询问所有用户）。 另外，用于个人身份验证的ASP.NET Core Identity模板现在有一个用户界面，允许用户下载他们的个人数据，以及完全删除他们的帐户。默认情况下，这些UI区域只返回来自ASP.NET Core标识的个人信息，并在标识表上执行删除操作。当您将自己的信息添加到您的数据库中时，您应该扩展这些功能以根据您的GDPR分析还包括这些数据。 最后，我们正在考虑扩展点来允许您应用自己的ASP.NET Core身份数据加密。我们建议您在尝试对自己的加密机制进行分层之前，先检查数据库的加密特征，以查看它们是否符合您的GDPR要求。Microsoft SQL和SQL Azure以及Azure表存储都提供了静态数据的透明加密，不需要对应用程序进行任何更改，并且可以为您进行管理。 安全 HTTPS 随着对安全和隐私的日益关注，为Web应用程序启用HTTPS比以往更加重要。HTTPS的执行在网络上变得越来越严格，不使用网站的网站被认为是越来越严格的标签。GDPR需要使用HTTPS来保护用户的隐私。在生产环境中使用HTTPS至关重要，在开发过程中使用HTTPS也可以帮助防止部署之前的相关问题，如不安全的链接。 在默认情况下 为了促进安全的网站开发，我们默认启用ASP.NET Core 2.1中的HTTPS。从2.1开始，除了在http：// localhost：5000上列出之外，当本地开发证书存在时，Kestrel将在https：// localhost：5001上侦听。在安装.NET Core SDK时将创建一个合适的证书，或者可以使用新的“dev-certs”工具手动设置。我们还将更新我们的项目模板以默认运行在HTTPS上，并包含HTTPS重定向和HSTS支持。 HTTPS重定向和执行 Web应用程序通常需要侦听HTTP和HTTPS，但是将所有HTTP通信重定向到HTTPS。ASP.NET Core 2.0具有可用于此目的的URL重写中间件，但正确配置可能会非常棘手。在2.1中，我们将介绍专门的HTTPS重定向中间件，该中间件根据配置或绑定服务器端口的存在情况进行智能重定向。 HTTP严格传输安全协议（HSTS）可以进一步强化HTTPS的使用，它指示浏览器始终通过HTTPS访问站点。ASP.NET Core 2.1添加了支持Max Age，子域和HSTS预加载列表选项的HSTS中间件。 生产配置 在生产中，必须明确配置HTTPS。在2.1版本中，我们引入了默认的配置模式来为Kestrel配置HTTPS，这个过程简单明了。您可以配置多个端点，包括要从磁盘上的文件或证书存储中使用的HTTPS的URL和证书。 虚拟身份验证方案 我们正在增加一些名为“虚拟方案”的案例来解决两个主要的情况： 身分 作为图书馆的身份 ASP.NET Core Identity为您提供了一个框架，用于为您的站点设置身份验证和身份关系，包括用户注册，密码管理，双因素身份验证，社交登录等等。但是，设置一个站点以使用ASP.NET Core Identity需要相当多的代码。尽管项目模板有助于生成此代码，但它们无助于将标识添加到现有应用程序，并且代码不能轻易更新。 身份的脚手架 如果您希望所有的身份代码都在您的应用程序中，以便您可以根据需要进行更改，则可以使用新的身份验证工具将身份代码添加到您的应用程序中。所有脚手架的身份代码都是在身份特定的区域文件夹中生成的，以便与应用程序代码保持良好的分离。 选项改进 要在配置的服务的帮助下配置选项，您现在可以实现IConfigureOptions HttpClientFactory 新的HttpClientFactory类型可以注册，并用于在应用程序中配置和使用HttpClient的实例。它提供了几个好处： 为命名和配置HttpClient的逻辑实例提供一个中心位置。例如，您可以配置一个预配置为访问GitHub的“github”客户端和一个用于其他用途的默认客户端。 通过在HttpClient中委托处理程序并实现基于Polly的中间件来利用这一点，对传出中间件的概念进行编码。 管理HttpClientMessageHandlers的生命周期，以避免在自己管理HttpClient生命周期时可能遇到的常见问题。 HttpClient已经具有委托处理程序的概念，可以将这些处理程序链接在一起以便传出HTTP请求。工厂将使这些每个命名客户端的注册更加直观，并且实现允许Polly策略用于重试，CircuitBreakers等的Polly处理程序。其他“中间件”也可以在未来实现，但是我们还没有知道什么时候会。 红隼 运输延伸性 底层libuv连接语义的当前实现已经从Kestrel的其他部分中分离出来，并被抽象为一个新的Transport抽象。虽然我们继续使用libuv作为默认传输，但是我们也增加了对基于.NET中包含的套接字类型的新传输的支持。 套接字传输 我们正在继续投资一个新的Kestrel插座运输，因为我们相信它有可能比现有的libuv运输更有效率。虽然我们还没有完成，但您仍然可以轻松地切换到新的套接字传输并今天尝试。 默认配置 我们正在为Kestrel添加配置端点和HTTPS设置的支持（请参阅HTTPS：生产配置） ASP.NET核心模块 ASP.NET核心模块（ANCM）是IIS的全局IIS模块，充当从IIS到Kestrel后端的反向代理。 版本敏捷性 由于ANCM是一个全球性的单身人士，因此无法像ASP.NET Core的其他部分一样灵活地进行版本管理。在2.1中，我们将ANCM重构为两部分：垫片和请求处理程序。填充程序将继续作为全局单例安装，但请求处理程序将作为新的Microsoft.AspNetCore.Server.IIS程序包的一部分提供，该程序包可由应用程序直接引用。这将允许您在不同的应用程序部署中使用不同版本的ANCM。 进程内托管 在2.1中，我们正在为基于.NET Core应用程序的ANCM添加一个新的进程内模式，其中运行时和您的应用程序都在IIS工作进程（w3wp.exe）中加载。这消除了通过回送适配器的代理请求的性能损失。我们的初步测试显示，与耗尽流程相比，性能提高了约4.4倍。配置您的应用程序以使用进程内模型可以使用`web.config`完成，并且最终将成为针对2.1的新应用程序的默认设置。 新的Microsoft.AspNetCore.App包 ASP.NET Core 2.1将引入一个新的元程序包供应用程序使用：Microsoft.AspNetCore.App。新的元程序包不同于现有的元程序包，因为它将ASP.NET或.NET团队不拥有或支持的程序包的依赖关系减少到确保主要框架功能运行所需的程序包数量。我们将更新项目模板以使用新的元数据包。现有的Microsoft.AspNetCore.All元程序包将继续在整个2.x生命周期中可用。 |
|
|
来自： 昵称11935121 > 《未命名》
