1.2 何时选择ASP.NET Core
希望您现在已经大致了解了ASP.NET Core是什么以及它是如何设计的。但问题仍然存在：你应该使用它吗？微软建议所有新的.NET web开发都应该使用ASP.NET Core，但对于任何开发人员或公司来说，切换或学习新的web stack 都是一个很大的要求。在本节中，将介绍
- 您可以使用ASP.NET Core构建什么类型的应用程序
- ASP.NET Core的一些亮点
- 为什么您应该考虑将ASP.NET Core用于新应用程序
- 将现有ASP.NET应用程序转换为ASP.NET Core之前需要考虑的事项
1.2.1 您可以构建什么类型的应用程序？
ASP.NET Core提供了一个通用的web框架，可用于各种应用程序。很明显，它可以用于构建丰富、动态的网站，无论是电子商务网站、基于内容的网站还是大型N层应用程序，这与ASP.NET的前一版本非常相似。
当.NETCore最初发布时，很少有第三方库可用于构建这些类型的复杂应用程序。经过几年的积极发展，情况已不再如此。许多开发人员已经更新了他们的库以使用ASP.NET Core，并且创建了许多其他库以专门针对ASP.NET Core。例如，开源内容管理系统（CMS）Orchard 已被重新开发为Orchard Core，以在ASP.NET Core上运行。相比之下，cloudscribe CMS项目（图1.5）从一开始就专门为ASP.NET Core编写。
图1.5 .NET Foundation网站(https://dotnetfoundation.org/)使用cloudscribe CMS和ASP.NET Core构建。
开发传统服务器端呈现的基于页面的web应用程序是ASP.NET开发的面包和黄油，无论是早期版本的ASP.NET还是ASP.NET Core。此外，使用客户端框架（通常与REST服务器对话）的单页应用程序（SPA）很容易使用ASP.NET Core创建。无论您使用的是Angular、Vue、React还是其他客户端框架，都很容易创建ASP.NET Core应用程序来充当服务器端API。
定义：REST代表状态转移。RESTful应用程序通常使用轻量级和无状态HTTP调用来读取、发布（创建/更新）和删除数据。
ASP.NET Core不限于创建RESTful服务。根据您的需求，很容易为应用程序创建web服务或远程过程调用（RPC）风格的服务，如图1.6所示。在最简单的情况下，您的应用程序可能只公开一个端点，从而缩小其范围，成为一个微服务。ASP.NET Core非常适合构建简单的服务，这得益于它的跨平台支持和轻量级设计。
图1.6 ASP.NET Core可以充当各种客户端的服务器端应用程序：它可以为传统web应用程序提供HTML页面，它可以充当客户端SPA应用程序的REST API，也可以充当客户端应用程序的临时RPC服务。
注意：在本文中，我们重点关注构建传统的、基于页面的服务器端呈现的web应用程序和RESTful web API。当然，在第22章中也展示了如何创建“Headless”工作服务。
在选择平台时，您应该考虑多个因素，但不是所有因素都是技术性的。其中一个因素是您可以从其创建者那里获得支持的水平。对于一些组织来说，这可能是采用开源软件的主要障碍之一。幸运的是，微软已承诺从.NET Core和ASP.NET Core发布之日起至少三年内为长期支持（LTS）版本提供全面支持。由于所有的开发都是在公开的环境中进行的，有时您可以从普通社区以及直接从Microsoft那里获得问题的答案。
在决定是否使用ASP.NET Core时，您需要考虑两个主要方面：您是否已经是.NET开发人员，以及您是在创建新应用程序还是在转换现有应用程序。
1.2.2 如果您是.NET开发新手
如果您是.NET开发新手，并且正在考虑ASP.NET Core，那么欢迎光临！微软正在将ASP.NET Core作为web开发初学者的有吸引力的选择，但采用.NET跨平台意味着它在自己的地盘上与许多其他框架竞争。与其他跨平台web框架相比，ASP.NET Core有许多卖点：
- 这是一个现代、高性能、开源的web框架。
- 它使用熟悉的设计模式和范例。
- C#是一种很棒的语言（如果您愿意，也可以使用VB.NET或F#）。
- 您可以在任何平台上构建和运行。
ASP.NET Core是对ASP.NET框架的重新构建，在新的.NETCore/.NET 5.0平台之上使用现代软件设计原则构建。尽管在某种意义上是新的，但.NETCore已经在生产中广泛使用了几年，并从已经使用了近二十年的成熟、稳定和可靠的.NET Framework中得到了很大的借鉴。您可以放心地认为，通过选择ASP.NET Core和.NET5.0，您将获得一个可靠的平台以及一个功能齐全的web框架。
今天可用的许多web框架都使用了类似的成熟设计模式，ASP.NET Core也不例外。例如，Rubyon Rails以其使用模型-视图-控制器（MVC）模式而闻名；Node.js以使用小型离散模块（称为管道）处理请求的方式而闻名；在各种各样的框架中都可以找到依赖关系。如果您熟悉这些技术，您应该会发现很容易将它们转移到ASP.NET Core；如果它们对您来说是新的，那么您可以期待您将要使用的是行业最佳的设计模式！
注意：您将在第3章中遇到管道，在第4章中遇到MVC，在第10章中遇到依赖注入。
C#是.NET开发的主要语言，特别是ASP.NET Core。这种语言有大量的追随者，这是有充分理由的！作为一种面向对象的基于C的语言，它为那些使用C、Java和许多其他语言的人提供了一种熟悉感。此外，它还有许多强大的功能，如语言集成查询（LINQ）、闭包和异步编程构造。C#语言也是在GitHub上公开设计的，微软的C#编译器也是如此，代码为Roslyn。
注意：本书中主要使用C#，并将重点介绍它提供的一些新功能，但我不会从头开始教这种语言。如果你想学习C#，我推荐Jon Skeet的第四版《C# in Depth》（Man-ning，2019）和Jort Rodenburg的《Code like a Pro in C#》（Manning，2021）。
ASP.NET Core和.NET5.0的主要卖点之一是能够在任何平台上开发和运行。无论您使用的是Mac、Windows还是Linux，都可以运行相同的ASP.NET Core应用程序，并在多个环境中进行开发。作为Linux用户，支持多种发行版（RHEL、Ubuntu、Debian、CentOS、Fedora和openSUSE等），因此您可以放心选择的操作系统将是一个可行的选择。ASP.NET Core甚至在小型Alpine分发版上运行，以实现对容器的真正紧凑部署。
内置容器
传统上，web应用程序直接部署到服务器或者虚拟机。虚拟机允许操作系统安装在虚拟硬件层中，从而抽象出底层硬件。与直接安装相比，这有几个优点，例如易于维护、部署和恢复。不幸的是，在文件大小和资源使用方面要求很高。
这也是引入容器的原因。容器要轻巧得多，而且没有虚拟机的开销。它们构建在一系列层中，在启动时不需要启动新的操作系统。这意味着它们启动快速，非常适合快速调配。容器，特别是Docker，正在迅速成为构建大型可扩展系统的首选平台。
对于ASP.NET应用程序来说，容器从来都不是一个特别有吸引力的选项，但随着ASP.NET Core、.NET 5.0和Docker for Windows的应用，这一切都在改变。在跨平台.NET5.0框架上运行的轻量级ASP.NET Core应用程序非常适合瘦容器部署。您可以在第16章中了解有关部署选项的更多信息。
除了在每个平台上运行之外，.NET的卖点之一是只需要编写和编译一次。您的应用程序被编译为中间语言（IL）代码，这是一种独立于平台的格式。如果目标系统安装了.NET 5.0运行时，则可以运行从任何平台编译的IL。这意味着，例如，您可以在Mac或Windows机器上开发，并将完全相同的文件部署到生产Linux机器上。这一编译一次，随时随地运行的承诺最终通过ASP.NET Core和.NET Core/.NET 5.0实现。
1.2.3 如果您是正在创建新应用程序.NET Framework开发人员
如果您是一名.NET开发人员，那么选择是否使用ASP.NET Core开发新应用程序在很大程度上取决于时间。早期版本的.NET Core缺少一些功能，难以采用。随着.NET Core 3.1和.NET 5.0的发布，这不再是问题；Microsoft现在明确建议所有新的.NET应用程序都应使用.NET 5.0。Microsoft已承诺为旧的ASP.NET框架提供错误和安全修复，但不会提供更多功能更新。NET Framework未被删除，因此旧应用程序将继续工作，但不应将其用于新开发。
ASP.NET Core与以前的ASP.NET框架相比的主要优势是
- 跨平台开发和部署
- 将性能作为一项功能
- 简化的托管模型
- 定期发布，发布周期更短
- 开源
- 模块化功能
作为一名.NET开发人员，如果您没有使用任何特定于Windows的构造（如注册表），那么跨平台构建和部署的能力将打开一扇全新的应用程序之门：利用云中更便宜的Linux VM托管，使用Docker容器进行可重复的连续集成，或者在Mac上编写.NET代码，而无需运行Windows虚拟机。ASP.NET Core与.NET 5.0相结合，使这一切成为可能。
.NET Core和.NET 5.0本质上是跨平台的，但如果需要，您仍然可以使用特定于平台的功能。例如，可以使用兼容包启用特定于Windows的功能，如注册表或目录服务，使这些API在.NET 5.0.6中可用，因此，您需要注意此类应用程序仅在Windows环境中运行，而且时刻注意可能丢失的APIs。
以前的ASP.NET框架的托管模型是一个相对复杂的模型，依赖于Windows IIS来提供web服务器托管。在跨平台环境中，这种共生关系是不可能的，因此采用了一种替代的宿主模式，将web应用程序与底层宿主分离。这一机会导致了Kestrel的诞生：一个快速、跨平台的HTTP服务器，ASP.NET Core可以在其上运行。
ASP.NET Core应用程序是一种控制台应用程序，它可以自行托管web服务器并直接处理请求，而不是以前的设计，即IIS调用应用程序的特定点，如图1.7所示。这种托管模型在概念上要简单得多，允许您从命令行测试和调试应用程序，尽管它不一定消除在生产环境中运行IIS（或等效）的需要，正如您将在第1.3节中看到的那样。
图1.7 ASP.NET（顶部）和ASP.NET Core（底部）中托管模型之间的差异。在ASP.NET的早期版本中，IIS与应用程序紧密耦合。ASP.NET Core中的托管模型更简单；IIS将请求交给ASP.NET Core应用程序中的自托管web服务器并接收响应，但对应用程序没有更深入的了解。
注：您还可以选择在IIS内部运行ASP.NET Core，如图1.7所示，这可以比反向代理版本具有性能优势。这主要是一个部署细节，不会改变您构建ASP.NET Core应用程序的方式。
将托管模型更改为使用内置HTTP web服务器，这又创造了一个机会。在过去，性能一直是ASP.NET应用程序的一个痛点。当然，构建高性能应用程序堆栈溢出是可能的(https://stackoverflow.com)证明了这一点，但web框架本身的设计并没有将性能作为优先事项，因此它可能会成为某种障碍。
为了在跨平台上具有竞争力，ASP.NET团队致力于使Kestrel HTTP服务器尽可能快。TechEmpower（www.technempower.com/benchmarks）多年来一直在各种语言的web框架上运行基准测试。在第19轮纯文本基准测试中，TechEmpower宣布ASP.NET Core和Kestrel是测试的400多个框架中最快的！
Web服务器的命名难题
网络编程的一个困难方面是一系列经常相互冲突的术语，令人困惑。例如，如果您过去使用过IIS，您可能会将其描述为web服务器，或者可能是web主机。相反，如果您曾经使用Node.js构建过应用程序，那么您可能也将该应用程序称为web服务器。或者，您可以调用应用程序运行web服务器的物理机器！
类似地，您可能已经为internet构建了一个应用程序，并将其称为网站或web应用程序，这可能是基于其显示的动态级别而任意决定的。
在本书中，当我在ASP.NET Core上下文中说“web服务器”时，我指的是作为ASP.NET Core应用程序的一部分运行的HTTP服务器。默认情况下，这是Kestrel web服务器，但这不是必需的。如果您愿意，可以编写一个替代web服务器并将其替换为Kestrel。
web服务器负责接收HTTP请求并生成响应。在ASP.NET的早期版本中，IIS扮演了这个角色，但在ASP.NET Core中，Kestrel是web服务器。
在本书中，我只使用“web应用程序”一词来描述ASP.NET Core应用程序，无论它们是仅包含静态内容还是完全动态的。无论哪种方式，它们都是通过网络访问的应用程序，因此这个名称似乎最合适。
Kestrel的许多性能改进并不是来自ASP.NET团队成员本身，而是来自GitHub开源项目的贡献者。在开放环境中开发意味着您通常会看到修复程序和功能比以前版本的ASP.NET更快地进入生产环境，因为ASP.NET依赖于.NET Framework和Windows，因此发布周期较长。
相比之下，.NET 5.0，以及ASP.NET Core，被设计为以较小的增量发布。主要版本将以可预测的节奏发布，每年发布一次新版本，每两年发布一次长期支持（LTS）新版本。此外，可以在需要时发布bug修复和小更新。附加功能以NuGet包的形式提供，独立于基础.NET 5.0平台。
注意：NuGet是一个.NET包管理器，它支持将库导入到项目中。它相当于Ruby Gems、npm for JavaScript 或 Maven for Java。
为了实现这种发布方法，ASP.NET Core是高度模块化的，与其他功能的耦合尽可能少。这种模块化为依赖关系提供了一种 pay-for-play 方法，即从一个简单的应用程序开始，只添加所需的附加库，而不是以前ASPNET应用程序的 kitchen-sink 方法。甚至MVC也是一个可选的包！但别担心，这种方法并不意味着ASP.NET Core缺少功能；这意味着你需要有选择地加入他们。一些关键的基础改进包括
- 用于定义应用程序行为的中间件“管道”
- 对依赖注入的内置支持
- 组合的UI（MVC）和API（Web API）基础架构
- 高度可扩展的配置系统
- 默认情况下，使用异步编程可扩展到云平台
这些功能中的每一个在ASP.NET的早期版本中都是可能的，但需要大量的额外工作来设置。有了ASP.NET Core，他们都准备就绪，等待连接！
微软完全支持ASP.NET Core，所以如果你想构建一个新系统，没有什么理由不使用它。您可能遇到的最大障碍是希望使用ASP.NET Core中不再支持的编程模型，例如Web表单或WCF服务器，我将在下一节中讨论。
希望本节已经激发了您使用ASP.NET Core构建新应用程序的兴趣。但是，如果您是一名现有的ASP.NET开发人员，正在考虑是否将现有的ASP.NET应用程序转换为ASP.NET Core，这完全是另一个问题。
1.2.4 将现有ASP.NET应用程序转换为ASP.NET Core
与新的应用程序相比，现有的应用程序可能已经提供了价值，因此在从ASP.NET转换为ASP.NET Core的过程中，执行可能相当于重大重写的操作应该总是有实际好处的。采用ASP.NET Core的优点与新应用程序的优点大致相同：跨平台部署、模块化功能和注重性能。福利是否充分将在很大程度上取决于您的应用程序的具体情况，但有一些特征是明确的转换指标：
- 应用程序使用ASPNET Web窗体
- 您的应用程序是使用WCF构建的
- 您的应用程序很大，具有许多“高级”MVC功能
如果您有ASP.NET Web表单应用程序，则不建议尝试将其转换为ASP.NET Core。Web表单与System.Web.dll密不可分，因此在ASP.NET Core中可能永远不可用。将应用程序转换为ASP.NET Core将导致从零开始重写应用程序，不仅改变框架，而且改变设计范式。更好的方法是慢慢引入Web API概念，并尝试减少对传统Web表单结构（如ViewData）的依赖。您可以在网上找到许多资源来帮助您使用这种方法，特别是www.ASPNET/web-api 网站。
ASP.NET Core仅部分支持Windows Communication Foundation（WCF）。使用一些WCF服务是可能的，但支持充其量是不稳定的。没有支持从ASP.NET Core应用程序托管WCF服务的方法，所以如果您绝对必须使用WCF，那么目前最好避免使用ASP.NET Core。
提示：如果您喜欢WCFs RPC风格的编程，但对WCF本身没有硬性要求，请考虑改用gRPC。gRPC是一个现代RPC框架，具有许多类似于WCF的概念，并且由ASP.NET Core开箱即用支持。
如果您现有的应用程序很复杂，并且大量使用了以前的MVC或Web API扩展点或消息处理程序，那么将您的应用程序移植到ASP.NET Core可能会更加困难。ASP.NET Core与ASP.NET MVC的早期版本具有许多相似的功能，但底层架构有所不同。之前的几个功能没有直接替换，因此需要重新思考。
应用程序越大，将应用程序转换为ASP.NET Core的难度就越大。微软自己认为，将应用程序从ASP.NET MVC移植到ASP.NET Core至少与将ASP.NET Web表单移植到ASP.NET MVC一样大。如果这不会吓到你，那么什么都不会吓到！
如果应用程序很少使用，不是您核心业务的一部分，或者在短期内不需要重大开发，我强烈建议您不要尝试将其转换为ASP.NET Core。在可预见的将来，Microsoft将支持.NET Framework（Windows本身依赖于它！），而转换这些“边缘”应用程序的回报不太值得。
那么，什么时候应该将应用程序移植到ASP.NET Core？正如我已经说过的，最好的开始机会是在小的应用领域，新的项目，而不是现有的应用程序。也就是说，如果所讨论的现有应用程序很小，或者将来需要大量开发，那么移植可能是一个不错的选择。在可能的情况下，最好在小的迭代中工作，而不是试图一次转换整个应用程序。但如果您的应用程序主要由MVC或WebAPI控制器和相关的Razor视图组成，那么迁移到ASP.NET Core可能是一个不错的选择。
标签：Core,ASP,web,应用程序,使用,NET From： https://www.cnblogs.com/SoftwareLife/p/16943392.html