常用 Web 应用程序体系结构【代码之美系列】

m0_74825488

于 2024-12-25 23:55:46 发布

阅读量942

点赞数 23

文章标签：前端

本文链接：https://blog.youkuaiyun.com/m0_74825488/article/details/144730966

版权

7.2 其他 Web 应用程序体系结构样式

7.4 参考 - 常见 Web 体系结构

“如果你认为好的体系结构很昂贵，试试糟糕的体系结构吧。”- Brian Foote 和 Joseph Yoder

大多数传统 .NET 应用程序都部署为单一单位，对应于单一 IIS 应用域中运行的可执行文件或单个 Web 应用程序。此方法是最简单的部署模型，能很好地为众多内部和小型公共应用程序提供服务。然而，即使提供此单一单位部署，大多数重要的商业应用程序仍受益于逻辑分层。

一、什么是整体式应用程序？

就其行为而言，整体式应用程序是完全独立的应用程序。在执行操作的过程中，该应用程序可能与其他服务或数据存储发生交互，但其核心业务在其自身进程中运转，且整个应用程序通常作为单个单位部署。如果此类应用程序需要横向扩展，通常需要在多个服务器或虚拟机中复制整个应用程序。

二、一体式应用程序

应用程序体系结构项目可能的最小数量是一。在这种体系结构中，应用程序的完整逻辑包含在单一项目中，编译为单一程序集并作为单个单元进行部署。

一个新的 ASP.NET Core 项目，不管是在 Visual Studio 中还是通过命令行创建，最初都是简单的“一体式”整体应用程序。它包含应用程序的所有行为，包括展现、业务和数据访问逻辑。图 5-1 展示了单项目应用的文件结构。

A single project ASP.NET Core app

**图 5-1.**单项目 ASP.NET Core 应用。

在单项目方案中，通过使用文件夹实现关注点分离。默认模板包括单独的文件夹，对应于 MVC 模式中的模型、视图和控制器，以及其他数据和服务文件夹。在这种结构安排中，应尽可能地将展现逻辑限制在“Views”文件夹，将数据访问逻辑限制在“Data”文件夹中保存的类。业务逻辑应位于“Models”文件夹内的服务和类中。

尽管简单，但单项目整体解决方案也有一些缺点。随着项目的大小和复杂性增加，文件和文件夹数量也会继续随之增加。用户界面 (UI) 问题（模型、视图和控制器）驻留于多个文件夹中，这些文件夹未按字母顺序组合在一起。将其他 UI 级别的构造（例如筛选器或 ModelBinder）添加到它们自己的文件夹时，问题只会变得更糟。业务逻辑分散于“Models”和“Services”文件夹之间，没有明确地指示哪些文件中的哪些类应当依赖其他类。这种项目级别缺少组织的情况通常会导致面条式代码。

为解决这些问题，应用程序通常演变为多项目解决方案，其中将每个项目视为位于应用程序的特定层。

三、什么是层次？

随着应用程序的复杂性增加，管理复杂性的方式之一是根据职责或问题分解应用程序。此方法遵循关注点分离原则，有助于使基本代码井然有序，以便开发人员可轻松找到实现特定功能的位置。然而，分层体系结构提供的好处远远不止于组织代码结构。

通过将代码分层排列，常见的低级功能可在整个应用程序中重复使用。这种重复使用很有用，因为它意味着需要编写的代码变少，还因为它可以让应用程序能够对某个实现进行标准化，从而遵循不要自我重复 (DRY)原则。

借助分层体系结构，应用程序可以强制实施有关哪些层可以与其他层通信的限制。此体系结构有助于实现封装。某层发生更改或更换时，只有与它一起工作的那些层会受到影响。通过限制哪些层依赖其他层，可缓解更改的影响，使一项更改不会影响整个应用程序。

分层（和封装）让替换应用程序内的功能变得更加轻松。例如，应用程序最初可能使用自己的 SQL Server 数据库来实现持久性，但稍后可能选择使用基于云的持久性策略，或 Web API 后的策略。如果应用程序将其持久性实现正确封装于逻辑层中，则可使用实现相同公共接口的新的 SQL Server 特定层替换它。

除可能的交换实现，以应对将来的要求更改之外，应用程序层还能让测试用途的交换实现变得更加轻松。无需编写针对应用程序的真实数据层或 UI 层操作的测试，可在测试时使用提供请求的已知响应的假实现来替换这些层。通常情况下，与针对应用的实际基础结构运行测试相比，此方法可以降低测试的编写难度，并提高测试的运行速度。

最低0.47元/天解锁文章