aspnet与asp的区别

一切都要从历史的源头说起。1.古代技术1.经典ASP开发:ASP是通过交叉标记和服务器端脚本创建动态的、数据驱动的网站和应用程序的主要技术。2.Windows开发:WinForm和WebForm

一切都要从历史的源头说起。

1.古代技术

1.经典ASP开发:ASP是通过交叉标记和服务器端脚本创建动态的、数据驱动的网站和应用程序的主要技术。

2.Windows开发:WinForm和WebForm

历史遗留问题

1.System.web程序集太大，具有逻辑上不同的功能单元，并且内部对象紧密耦合。

2.ASP.NET是世界的一部分。NET Framework，而且版本之间的时间会以年为单位，这样ASP.NET很难跟上不断发展的Web开发中发生的所有变化。

3.System.web与IIS的关系过于密切

2.进化:ASP.NET的MVC和ASP.NET的Web API

Web开发经历了翻天覆地的变化。Web应用程序越来越多地被开发成一系列小型的集中式组件，而不是大型的框架。组件的数量及其发布频率在不断增加。显然，要跟上Web的发展步伐，框架需要更小、解耦、更专注，而不是更大、功能更丰富。因此，ASP.NET团队采取了几个步骤将ASP.NET开发成一系列可插拔的网络组件，而不是一个单一的框架。

最早的变化之一是众所周知的模型视图控制器(MVC)设计模式的流行，这要归功于Web开发框架，如Ruby on Rails。构建这个Web应用程序使开发人员能够更好地控制他们应用程序的标记，同时仍然保持标记和业务逻辑的分离，这是ASP.NET最初的卖点之一。为了满足这种风格的Web应用程序开发的需要，微软通过开发ASP.NET MVC而不是将其包含在。NET框架。ASP.NET MVC是作为独立下载发布的。这使得工程团队能够比以前更频繁地发布更新。

Web应用开发的另一个重要变化是从动态的、服务器生成的网页到静态的初始标记的变化，其中页面的动态部分由客户端脚本通过AJAX请求与后端Web api通信生成。这种架构上的变化促进了Web API的兴起和Web API框架在ASP.NET的发展。就像ASP.NET MVC一样，ASP.NET Web API提供了另一个机会将ASP.NET开发成一个更加模块化的框架。工程团队利用这个机会建立了ASP.NET Web API，因此它不依赖于System.web中的任何核心框架类型

让这两件事成为可能:

首先意味着ASP.NET Web API可以完全独立开发(因为是通过NuGet提供的，所以可以继续快速迭代)。

其次，因为对System.web没有外部依赖，所以对IIS也没有依赖。ASP.NET Web API包括在自定义主机(例如，控制台应用程序、Windows服务等)上运行的能力。).

3.未来:灵活的框架

通过将框架组件相互分离，然后在NuGet上发布，现在可以更加独立和快速地迭代框架。此外，Web API强大而灵活的自托管功能对于希望为其服务提供小型轻量级主机的开发者来说非常有吸引力。其实这是一个很好的方法。事实上，它是如此吸引人，以至于其他框架都想要这个功能，同时也带来了新的挑战，因为每个框架都在自己的基址运行在自己的宿主进程中，需要独立管理(启动、停止等。).现代Web应用程序通常支持静态文件服务、动态页面生成、Web API和最新的实时/推送通知。期望每个服务独立运行和管理是不现实的。

我们需要的是一个单一的托管抽象，它将使开发人员能够组合来自各种不同组件和框架的应用程序，然后在支持主机上运行该应用程序。

4.的开放Web界面(OWIN)。网

受到Ruby社区中Rack的好处的启发，一些。net社区开始在Web服务器和框架组件之间创建抽象。OWIN抽象的两个设计目标是简单性和最小化对其他框架类型的依赖。这两个目标有助于确保:

可以更容易地开发和使用新组件。应用程序可以更容易地在主机和整个平台/操作系统之间移植。

最终的抽象包含两个核心元素。第一本是环境词典。这个数据结构负责存储处理HTTP请求和响应所需的所有状态，以及任何相关的服务器状态。该词典定义如下:

字典& lt字符串，对象& gtOwin兼容的Web服务器负责用数据填充环境字典，比如HTTP请求和响应的主体流和头集合。然后，应用程序或框架组件负责用添加的值填充或更新字典，并将其写入响应主体流。

除了指定环境字典的类型，OWIN规范还定义了核心字典的键值对列表。

OWIN的第二个关键要素是应用程序授权。这是一个函数签名，作为OWIN应用程序中所有组件之间的主接口。应用程序委托的定义如下:

Func & lt字典& lt字符串，对象& gt，任务& gt应用程序委托只是Func委托类型的一个实现，其中函数将环境字典作为输入并返回任务。这个设计对开发者有以下启发:

编写OWIN组件所需的类型依赖数量非常少。这极大地增加了OWIN对开发者的易接近性。异步设计使抽象能够有效地处理计算资源，尤其是在I/O密集型操作中。因为应用程序委托是一个原子执行单元，并且环境字典作为委托的一个参数，所以OWIN组件可以很容易地链接在一起以创建复杂的HTTP处理管道。

从实现的角度来看，OWIN是一个规范(http://owin.org/html/owin.html)。它的目标不是成为下一个Web框架，而是标准化Web框架和Web服务器的交互方式。

如果你学过OWIN或武士刀，你可能会注意到OWIN努杰包和OWIN。dll也是如此。这个库包含一个接口IAppBuilder，它对OWIN规范第4节中描述的启动序列进行了形式化和编码。虽然IAppBuilder接口不是构建OWIN服务器所必需的，但它提供了一个特定的参考点，供Katana项目组件使用。

5.武士刀项目

虽然OWIN的规格和OWIN一样。dll都是由社区拥有和运行的开源项目，Katana项目代表一组OWIN组件，它们都是由微软构建和发布的，尽管它们仍然是开源的。这些组件不仅包括基础设施组件(如主机和服务器)，还包括功能组件(如认证组件)和框架绑定(如SignalR和ASP。NET Web API)。该项目有以下三个高级目标:

可移植性——当新组件可用时，组件应该能够容易地替换它们。这包括从框架到服务器和主机的所有类型的组件。这个目标意味着第三方框架可以在微软服务器上无缝运行，而微软框架可能在第三方服务器和主机上运行。模块化/灵活性-与许多包含大量默认打开的功能的框架不同，Katana项目组件应该小而有针对性，并使应用程序开发人员能够决定控制要在应用程序中使用的组件的轻量级/高性能/可伸缩性-通过将框架的传统概念分解为一组由应用程序开发人员显式添加的小而集中的组件，最终的Katana应用程序可以消耗更少的计算资源， 因此，他们可以处理更多的负载，而不是因为应用程序的要求需要底层基础架构中的更多功能，这些功能可以添加到OWIN管道中，但这应该是应用程序开发人员的明确决定。 此外，低级组件的可替代性意味着当它们可用时，可以无缝地引入新的高性能服务器来提高OWIN应用的性能，而不会中断这些应用。

武士刀建筑

Katana组件架构将应用程序分为四个逻辑层，如下:主机、服务器、中间件和应用程序。组件架构的分解使得在许多情况下无需重新编译应用程序就可以轻松替换这些层的实现。

武士刀

主持

主机负责以下操作:

管理基本流程。安排工作流程，选择服务器并建立OWIN管道，通过该管道处理请求。

目前，基于武士刀的应用程序有3个主要的托管选项:

IIS/ASP。使用标准的HttpModule和HttpHandler类型，OWIN管道可以作为ASP.NET请求流的一部分在IIS上运行。ASP.NET主机支持是通过安装Microsoft。aspnet . host . system Web nu将包获取到Web应用程序项目中。此外，由于IIS同时作为主机和服务器，OWIN服务器/主机的差异被合并在NuGet包中，这意味着如果使用SystemWeb主机，开发人员无法替换替代的服务器实现。

自定义宿主:Katana组件套件允许开发人员在他们自己的自定义进程中托管应用程序，无论该应用程序是控制台应用程序、Windows服务等等。这个函数类似于Web API提供的自托管函数。

Owinhost.exe:虽然有些人希望编写一个自定义的进程来运行Katana Web应用程序，但许多人更喜欢简单地启动一个预先构建的可执行程序来启动服务器并运行其应用程序。对于这种情况，Katana组件套件包括“OwinHost.exe”。当在项目的根目录下运行时，这个可执行文件将启动一个服务器(它默认使用HttpListener服务器)，并使用约定来查找和运行用户的启动类。对于更细粒度的控制，可执行文件提供了许多额外的命令行参数。

计算机网络服务器

主机负责启动和维护应用程序运行的进程，而服务器的职责是打开一个网络套接字，侦听请求，并通过用户指定的OWIN组件管道(您可能已经注意到，这个管道是在应用程序开发人员的启动类中指定的)发送请求。目前，Katana项目包括两个服务器实现:

微软。Owin.Host.SystemWeb:如前所述，IIS同时充当ASP.NET管道的主机和服务器。因此，当选择此宿主选项时，IIS管理两个主机级问题(如进程激活和HTTP请求侦听)。对于ASP.NET web应用程序，它将请求发送到ASP.NET管道。Katana SystemWeb主机会注册ASP.NET HTTP模块和HttpHandler，在请求流经HTTP管道时进行拦截，并通过用户指定的OWIN管道发送。

微软。欧文。顾名思义，这个Katana服务器使用。NET Framework打开套接字，并将请求发送到开发人员指定的Owin管道。这是目前武士刀自托管API和Owinhost.exe的默认服务器选择。

中间件/框架

如前所述，当服务器接受来自客户端的请求时，它负责通过OWIN组件的管道传递请求，这些组件由开发人员的启动代码指定。这些管道组件被称为中间件。

在最底层的实现中，OWIN中间件只需要实现OWIN应用委托就可以被调用。

Func & lt字典& lt字符串，对象& gt，任务& gt但是，为了简化中间件组件的开发和组合，Katana支持一些中间件组件的约定和帮助类型。最常见的是OwinMiddleware类。使用该类构建的自定义中间件组件如下:

公共类logger middleware:OwinMiddleware { private readonly ILog _ logger；public logger middleware(OwinMiddleware next，ILog logger):base(next){ _ logger = logger；}公共覆盖异步任务调用(IOwinContext上下文){ _logger。log info("中间件begin & # 034);等待这个。Next.Invoke(上下文)；_logger。log info("中间件端");}}该类派生自OwinMiddleware，实现了一个构造函数，该构造函数接受管道中下一个中间件的实例作为其参数之一，然后将其传递给基构造函数(base(next))。用于配置中间件的其他参数也在下一个中间件参数之后声明为构造器参数(ILog logger)。

在运行时，中间件通过被覆盖的Invoke方法执行。此方法使用OwinContext类型的单个参数。这个上下文对象是由前面提到的微软提供的。Owin NuGet包，并提供对请求、响应和环境字典以及其他一些帮助器类型的强类型访问。

您可以在应用程序启动代码中轻松地向OWIN管道添加中间件类，如下所示:

公共类启动{公共void配置(IAppBuilder app) { app。使用& ltLoggerMiddleware & gt(new trace logger())；}}由于Katana infrastructure只是简单地构建了OWIN中间件组件的管道，并且由于这些组件只需要支持应用委托就可以参与管道，因此中间件组件的复杂程度可以从简单的日志程序到整个框架(如ASP.NET、Web API或SignalR)不等。例如，将ASP.NET Web API添加到以前的OWIN管道需要添加以下启动代码:

公共类启动{公共void配置(IAppBuilder app) { app。使用& ltLoggerMiddleware & gt(new trace logger())；var config = new HttpConfiguration()；//配置Web API app。use webapi(config)；//附加中间件注册}} Katana infrastructure会根据中间件组件在配置方法中添加到IAppBuilder对象的顺序来构建它们的管道。在我们的示例中，LoggerMiddleware可以处理流经管道的所有请求，不管这些请求最终是如何处理的。这使得中间件组件(如认证组件)能够处理包含多个组件和框架(如ASP.NET Web API、SignalR和静态文件服务器)的管道请求。

应用程序

如前面的例子所示，OWIN和Katana项目不应被视为一种新的应用程序编程模型，而是一种抽象，将应用程序编程模型和框架从服务器和托管基础设施中分离出来。例如，在构建Web API应用程序时，开发人员框架将继续使用ASP.NET Web API框架，无论该应用程序是否使用Katana项目中的组件在OWIN管道中运行。应用程序开发人员可以看到OWIN相关代码的一个地方是应用程序启动代码，开发人员在那里形成OWIN管道。在启动代码中，开发人员将注册一系列UseXx语句，通常是每个中间件组件来处理传入的请求。这种体验和在当前系统中注册HTTP模块有异曲同工之妙。通常，较大的框架中间件(如ASP.NET Web API或SignalR)将在管道的末端注册。横切的中间件组件(AOP ),比如那些用于认证或缓存的组件，通常在管道的开始注册，这样它们就可以处理所有在管道后面注册的框架和组件的请求。中间件组件之间以及与底层基础设施组件之间的这种分离使组件能够以不同的速度开发，同时确保整个系统的稳定性。

组件-获取包

像许多当前的库和框架一样，Katana项目组件是作为一组NuGet包提供的。

武士刀项目中几乎每个包都直接或间接依赖于Owin包。您可能还记得，Owin包包含IAppBuilder接口，它提供了OWIN规范第4节中描述的应用程序启动序列的具体实现。此外，许多软件包依赖于微软。Owin，它提供了一组用于处理HTTP请求和响应的助手类型。包的其余部分可以分为托管基础设施包(服务器或主机)或中间件。Katana项目之外的包和依赖项显示为橙色。

Katana 2.0的托管基础设施包括基于SystemWeb和HttpListener的服务器、使用OwinHost.exe运行OWIN应用程序的OWINhost包和微软。Owin.Hosting包，在自定义主机中自托管Owin应用程序(如控制台应用程序和Windows服务)。

6.ASP.NET核心:开源、组件化和跨平台。

ASP.NET可以说是ASP.NET的升级版。它遵循的标准架构。NET并基于。网芯。

Web开发框架，可以在多种操作系统上运行。它更快，更容易配置，更模块化和更具可扩展性。

ASP.NET有以下优势:

模块化架构产生了Web UI和Web API的统一场景。为可测试性而构建。Razor页面可以使基于页面的编码更简单、更高效。Blazor允许在浏览器中使用C#和JavaScript。共享所有用。网。能够在Windows，macOS和Linux上开发和运行。开源和以社区为中心。使用gRPC来管理远程过程调用(RPC)。基于环境的云就绪配置系统。内置依赖注入。轻量级高性能模块化HTTP请求管道。异步编程友好

。网芯才是未来。

参考:

1.[项目Katana | Microsoft Docs概述](https://Docs . Microsoft . com/zh-cn/aspnet/Overview/Owin-and-Katana/an-Overview-of-Project-Katana)

2.[概述ASP.NET核心竞争力的发展和基础。净核心](https://www.cnblogs.com/Irving/p/5146976.html)

3、【ASP.NET核心中间件或OWIN中间件】(https://stack overflow . com/questions/39429122/ASP-net-Core-middleware-or-owin-middleware)

4、【从OWIN迁移到ASP.NET核心】(https://stack overflow . com/questions/35997873/Migrating-from-owin-to-ASP-net-Core)

5.【ASP.NET核心|微软文档简介】(https://Docs . Microsoft . com/zh-cn/aspnet/Core/Introduction-to-aspnet-Core？view=aspnetcore-6.0)

6.【选择aspnet核心UI |微软文档】(https://Docs . Microsoft . com/zh-cn/aspnet/Core/tutorials/choose-we b-UI？view=aspnetcore-6.0)