为服务器应用选择.NET Core或.NET Framework

服务器端应用程序可通过NET Framework和.NET Core两种方式生成。这两者共享许多相同的组件,可在它们之间共享代码。但两者之间存在根本的差异,可根据需要实现的目标进行选择。本文介绍了在何种情况下进行选择。

在以下情况,对服务器应用程序使用.NET Core:

1)用户有跨平台需求。

2)用户正在面向微服务。

3)用户正在使用Docker容器。

4)需要高性能和可扩展的系统。

5)需按应用程序提供并行的.NET版本。

在以下情况,对服务器应用程序使用.NET Framework:

1)应用当前使用.NET Framework(建议扩展而不是迁移)。

2)应用使用不可用于.NET Core的第三方.NET库或NuGet包。

3)应用使用不可用于.NET Core的.NET技术。

4)应用使用不支持.NET Core的平台。

选择.NET Core 的情形

以下各部分对前面提到的选择.NET Core的原因进行了进一步说明。

跨平台需求

如果应用程序(Web/服务)需要在多个平台(Windows、Linux和macOS)上运行,请使用.NET Core。

.NET Core作为开发工作站支持前面提到的操作系统。Visual Studio提供了适用于Windows和macOS的集成开发环境(IDE)。还可使用运行于macOS、Linux和Windows上的Visual Studio Code。Visual Studio Code支持.NET Core,包括IntelliSense和调试。大多数第三方编辑器(如Sublime、Emacs和VI)都可搭配.NET Core使用。这些第三方编辑器可使用Omnisharp获取编辑器IntelliSense。也可不使用任何代码编辑器,直接使用适用于所有支持平台的.NET Core CLI 工具。

微服务体系结构

微服务体系结构允许跨服务边界组合使用技术。通过这种技术组合,可逐步接受.NET Core作为能与其他微服务或服务搭配使用的新微服务。例如,可组合使用微服务或使用.NET Framework、Java、Ruby或其他单片技术开发的服务。

可用的基础结构平台有很多。Azure Service Fabric,设计用于大型和复杂微服务系统。Azure App Service,很适合用于无状态微服务。基于Docker的微服务备选方案适合任何一种微服务方法,这部分内容将在容器部分进行说明。所有这些平台都支持.NET Core,是托管微服务的理想选择。

容器

容器通常与微服务体系结构结合使用。还可使用容器将遵循任何体系结构模式的Web应用或服务容器化。可在Windows容器上使用.NET Framework,但.NET Core的模块化和轻型性质使之成为容器的更佳选择。在创建和部署容器时,使用.NET Core时容器的映像大小要远小于使用.NET Framework时的大小。例如,因为它是跨平台的,所以可将服务器应用部署到Linux Docker容器。

Docker容器可托管在自己的Linux或Windows基础结构中,或托管在Azure 容器服务等云服务中。Azure容器服务可管理、协调和缩放云中基于容器的应用程序。

高性能和可扩展系统的需求

如果系统需要最佳的性能和可伸缩性,.NET Core和ASP.NET Core是最佳的选择。Windows Server和Linux的高性能服务器运行时使.NET成为TechEmpower 基准上执行最佳的Web框架。

性能和可伸缩性对微服务体系结构尤为重要,体系结构中可能正在运行数百个微服务。借助ASP.NET Core,系统运行的服务器/虚拟机(VM)数要低得多。减少服务器/VM后可节省基础结构和托管成本。

需要按应用程序级别选择并行的.NET 版本

若要安装含不同.NET版本上的依赖项的应用程序,建议使用NET Core。通过.NET Core可在同一计算机上并行安装不同版本的.NET Core运行时。并行安装允许在同一服务器上使用多个服务,每个服务位于其相应的.NET Core版本上。这还可在应用程序升级和IT运营时降低风险、节省成本。

选择.NET Framework 的情形

.NET Core对新应用程序和应用程序模式特别有用。但是在很多现有方案中依然会自然而然地选择.NET Framework,并且对于所有服务器应用程序,.NET Framework不会被.NET Core代替。

现有的.NET Framework 应用程序

在大多数情况下,不需要将现有应用程序迁移到.NET Core。相反,若要扩展现有的应用程序(例如,在ASP.NET Core中写入新的Web服务),建议使用.NET Core。

需要使用不可用于.NET Core 的第三方 .NET 库或 NuGet 包

库很快将使用.NET Standard。通过.NET Standard可跨各种.NET实现(包括.NET Core)共享代码。使用.NET Standard 2.0则更简单:

1)API曲面已变为更大。

2)引入了.NET Framework兼容性模式。此兼容性模式允许.NET Standard/.NET Core项目引用.NET Framework库。

因此,只有在库或NuGet包使用的技术在.NET Standard/.NET Core中不可用的情况下,才需要使用.NET Framework。

需要使用不可用于.NET Core 的 .NET 技术

某些.NET Framework技术在.NET Core中不可用。其中一些技术可能在更高版本的.NET Core中可用。但其他技术不会应用于.NET Core面向的新应用程序模式,因此可能永远不可用。以下列表显示无法在.NET Core中找到的最常见技术:

1)ASP.NET Web窗体应用程序:ASP.NET Web窗体仅在.NET Framework中可用。ASP.NET Core不能用于ASP.NET Web窗体。目前没有将ASP.NET Web窗体引入.NET Core的计划。

2)ASP.NET网页应用程序:ASP.NET网页未包含在ASP.NET Core中。ASP.NET CoreRazor 页与网页有许多相似之处。

3)WCF服务的实现。虽然WCF 客户端库可从.NET Core使用WCF服务,WCF服务器实现目前只在.NET Framework上可用。这种情况虽然不属于.NET Core当前计划,但将来会考虑这点。

4)工作流相关的服务:Windows Workflow Foundation (WF)、工作流服务(WCF +单个服务中的WF)和WCF数据服务(以前称为“ADO.NET数据服务”)仅在.NET Framework上可用。尚未计划将WF/WCF+WF/WCF Data Services引入.NET Core。

5)语言支持:.NET Core目前支持Visual Basic和F#,但不是所有项目类型都支持。

除了正式的路线图,还有其他框架将植入.NET Core。若要查看完整列表,请参阅标记为port-to-core的CoreFX问题。此列表并不代表Microsoft承诺将这些组件引入.NET Core。这样做只是因为他们捕获到了社区所需。如果关注任何标记为port-to-core的组件,请在GitHub上参与讨论。如果认为遗漏了某些内容,请在CoreFX 存储库中提出新的问题。

需要使用不支持.NET Core 的平台

某些Microsoft或第三方平台不支持.NET Core。例如,某些Azure服务(如Service Fabric Stateful Reliable Services和Service Fabric Reliable Actors)需要.NET Framework。某些其他服务提供尚不可用于.NET Core的SDK。这只是过渡情况,因为所有Azure服务都将使用.NET Core。在此期间,可用始终使用等效的REST API取代客户端SDK。

文章参考微软官网

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20180816G1QZDC00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券