ASP .NET CORE 0: 典型的Web应用架构

其实通过几个大厂的文档就可以看出每个厂子的态度, 虽然都是在推销自己的产品, 但微软和谷歌显然更加对开发者更为友好. 谷歌关注开发者的成长, 微软注重软件工程实践传道. 个人也很喜欢看微软和谷歌的文档! 这篇文章就是从微软的文档中摘抄的内容.

如果你认为好的架构会导致更多的投入的话, 那请尝试使用一个烂架构再来对比.

把代码打包到一个可执行文件然后放到 Web 服务器上运行的做法对于小型工程十分简单且有效. 但是对于大多数商业工程而言, 需要的是一个合理分层(layer)的架构. 故从大方向上说, 就有两种不同的架构选择:

• All-in-one Application

  将所有代码都放到唯一的一个 Project 中管理, 打包的时候也生成单一的可执行文件. 这样的架构下, 关注点分离 原则是通过将代码放到不同的文件夹下实现的. 这样的架构实现起来非常简单, 但也存在许多缺陷. 最重要的一点就是不利于程序的扩展和维护, 随着需求的变化, 类的依赖关系以及程序内部数据流等内容的复杂度也在不断提高, 最终导致的就是形成一堆杂乱无章的代码. 为了解决这一问题, 故人们引入了第二种架构, 即分层架构.

• Multi-layer Application

  为了解决单工程架构存在的种种缺陷, 人们提出了一种新的方案, 即多层(layer)架构, 将不同的关注点分离到不同的层中, 层间通过接口进行通信. 就实现上来说, 不同的层代码会放到不同的 project 中. 分层的核心就是关注点分离, 分层也有利于实现 DRY, 因为功能是可重用的.

传统的 N-Layer 架构

传统的 N-Layer 架构分层如下图所示:

(三层的缩写分别是 UI, BLL, DAL)

在实现上, 可以将三层分别在不同的 Project 中实现.

清晰架构(Clean Architecture)概述

在传统 N-Layer 架构基础上, 结合依赖注入(DI) 以及 DDD 原则, 就形成了一种新的架构: 清晰架构.

清晰架构中, 将业务逻辑和业务模型放到一起形成应用的核心(Application Core). 和传统多层架构不同的是, 业务逻辑层不再直接依赖数据访问层, 而是数据访问层去依赖 APP 核心中提供的接口定义(抽象类或接口).

清晰架构的概念样式如下洋葱图所示:

UI 和数据访问层都依赖最内层的 Application Core 中提供的各种接口. 而 Application Core 没有对外的任何依赖.

如下以水平视角展示清晰架构:

其中实线箭头表示编译期依赖关系, 虚线箭头表示运行期依赖关系. 可以看到, 在编译期 UI 层是不会知道 DAL 层中的任何实现细节的, 而在运行期才由依赖注入将 DAL 层的对象和 UI 进行关联, 因为在编译期 UI 层只会使用 Core 中提供的接口.

下图是从 ANC 中的实现角度来看清晰架构:

正因为 Application Core 不依赖任何其他层, 故实现它的单元测试将非常简单!

且业务接口和数据访问接口都在 Application core 中定义, 故要替换数据访问实现也会非常简单!