前言

.Net目前支持构建服务器端应用程序的两种实现主要有两种，.NET Framework和.NET Core。两者共享许多相同的组件，并且您可以在两者之间共享代码。但是，两者之间存在根本差异，在我们选择使用哪种框架构建应用时，您的选择取决于您要完成的工作，以下说明两种框架的应用场景，希望能够帮助您做出最正确的选择。

在以下情况下，将.NET Core用于服务器应用程序：

• 您有跨平台的需求。
• 您正在针对微服务。
• 您正在使用Docker容器。
• 您需要高性能和可扩展的系统。
• 每个应用程序需要并行的.NET版本。
• 在以下情况下，将.NET Framework用于服务器应用程序：

您的应用当前使用.NET Framework（建议扩展而不是迁移）。

• 您的应用程序使用了.NET Core不可用的第三方.NET库或NuGet软件包。
• 您的应用使用了.NET Core无法使用的.NET技术。
• 您的应用使用的平台不支持.NET Core。 Windows，macOS和Linux支持.NET Core。

何时选择.NET Core

以下各节对前面所述选择.NET Core的原因进行了更详细的说明。

跨平台需求

如果您的应用程序（Web /服务）需要在多个平台（Windows，Linux和macOS）上运行，请使用.NET Core。

.NET Core支持将前面提到的操作系统作为您的开发工作站。 Visual Studio为Windows和macOS提供了集成开发环境（IDE）。您还可以使用Visual Studio Code，该代码可在macOS，Linux和Windows上运行。 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应用服务是无状态微服务的理想选择。如``容器’'部分所述，基于Docker的微服务替代品适合任何类型的微服务方法。所有这些平台都支持.NET Core，使其成为托管微服务的理想选择。

有关微服务体系结构的更多信息，请参见.NET微服务。容器化.NET应用程序的体系结构。

容器

容器通常与微服务架构结合使用。容器还可以用于容器化遵循任何体系结构模式的Web应用程序或服务。 .NET Framework可以在Windows容器上使用，但是.NET Core的模块化和轻量级的特性使其成为容器的更好选择。创建和部署容器时，.NET Core的映像大小比.NET Framework小得多。因为它是跨平台的，所以您可以将服务器应用程序部署到Linux Docker容器。

Docker容器可以托管在您自己的Linux或Windows基础结构中，也可以托管在诸如Azure Kubernetes Service之类的云服务中。 Azure Kubernetes Service可以在云中管理，协调和扩展基于容器的应用程序。

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

当您的系统需要最佳的性能和可伸缩性时，.NET Core和ASP.NET Core是您的最佳选择。 Windows Server和Linux的高性能服务器运行时使.NET成为TechEmpower基准测试中性能最高的Web框架。

性能和可伸缩性与可能正在运行数百个微服务的微服务体系结构特别相关。使用ASP.NET Core，系统运行的服务器/虚拟机（VM）数量少得多。减少的服务器/虚拟机节省了基础架构和托管成本。

每个应用程序级别并排的.NET版本的需求

要安装依赖于不同版本.NET的应用程序，建议使用.NET Core。 .NET Core可在同一台计算机上并行安装不同版本的.NET Core运行时。这种并行安装允许在同一服务器上提供多个服务，每个服务都在其自己的.NET Core版本上。它还降低了风险，并节省了应用程序升级和IT运营的费用。

何时选择.NET Framework

.NET Core为新的应用程序和应用程序模式提供了明显的好处。但是，对于许多现有方案而言，.NET Framework仍然是自然的选择，因此对于所有服务器应用程序，.NET Core都不会取代.NET Framework。

当前.NET Framework应用程序

在大多数情况下，您不需要将现有应用程序迁移到.NET Core。相反，建议的方法是在扩展现有应用程序时使用.NET Core，例如在ASP.NET Core中编写新的Web服务。

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

图书馆正在迅速拥抱.NET标准。 .NET Standard支持跨所有.NET实现（包括.NET Core）共享代码。使用.NET Standard 2.0，这甚至更加容易：

API的表面变得更大。

引入了.NET Framework兼容模式。此兼容模式允许.NET Standard / .NET Core项目引用.NET Framework库。要了解有关兼容模式的更多信息，请参见宣布.NET Standard 2.0。
因此，仅在库或NuGet软件包使用.NET Standard / .NET Core中不可用的技术的情况下，才需要使用.NET Framework。

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

.NET Core中不提供某些.NET Framework技术。其中一些可能在更高的.NET Core版本中可用。其他则不适用于.NET Core定位的新应用程序模式，并且可能永远不可用。以下列表显示了.NET Core中找不到的最常见技术：

ASP.NET Web窗体应用程序：

ASP.NET Web窗体仅在.NET Framework中可用。 ASP.NET Core不能用于ASP.NET Web窗体。没有计划将ASP.NET Web窗体引入.NET Core。

ASP.NET Web Pages应用程序：

ASP.NET Core中不包含ASP.NET Web Pages。

WCF服务实施。

即使有WCF-Client库可以使用.NET Core中的WCF服务，WCF服务器实现当前也仅在.NET Framework中可用。该方案不是当前.NET Core计划的一部分，但正在考虑将来使用。

与工作流相关的服务：

Windows Workflow Foundation（WF），工作流服务（单个服务中的WCF + WF）和WCF数据服务（以前称为“ ADO.NET数据服务”）仅在.NET Framework中可用。没有计划将WF / WCF + WF / WCF数据服务引入.NET Core。

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

某些Microsoft或第三方平台不支持.NET Core。某些Azure服务提供了尚无法在.NET Core上使用的SDK。这是一个过渡情况，因为所有Azure服务都使用.NET Core。同时，您始终可以使用等效的REST API代替客户端SDK。

结语

以上总结了.Net与.Net Framework之间的差异和每项的最佳使用场景，希望能够为刚上手.Net的朋友们答疑解惑。接下来我会陆续制作.Net与.Net Core相关基础教程，并分享到个人博客，希望大家能够关注支持，原创，喜欢的话记得帮忙点个赞。

本文由博客群发一文多发等运营工具平台 OpenWrite 发布