.NET逻辑分层架构总结

揭开.NET分层架构的神秘面纱

当我们谈及分层架构，许多技术功底相对较浅的程序员可能会立刻联想到三层架构（BLL、DAL等）。分层其实是一种更为广泛的技术框架思想，而三层架构则是针对普通信息系统的一种具体实现方式，通过三层来分解信息的流转。

一、基础知识准备

1. 层的原则

每一层应以接口方式供上层调用，上层只能调用下层，依赖分为松散交互和严格交互两种。

在业务逻辑方面，我们可以将其分为应用逻辑和领域逻辑。

在分层架构中，我们主要涉及到以下几种层：表示层（用户接口层，领域无关）、服务层（应用层，应用逻辑）、业务逻辑层（领域层，领域逻辑）、共享层（提供通用代码）以及实现层（提供接口实现）。

2. 约定

领域层默认采用领域模型，数据访问层默认需要引用领域模型。

二、分层架构

分层架构主要由表示层、业务逻辑层和数据访问层三个基本层次构成。如果按照业务逻辑的分类，我们可以将业务逻辑层进一步分解为服务层和领域层，从而将三层扩展为四层：表示层、服务层、领域层和数据访问层。

数据访问层一般必须了解领域模型，这会在层之间产生双向依赖。针对这个问题，我们有两种常见的解决方案：

1. 将领域模型放置在共享层。这种模型在PetShop中得到应用，但这种方法的缺点是领域模型实际上变成了数据模型，保持了层间依赖，引入了更多依赖，明显的数据驱动思想，没有以领域为核心。

2. 将数据访问接口定义在业务逻辑层。NopCommerce采用的就是这种模型。即使它分离出了服务层并采用了资源库命名方式，NopCommerce仍不是真正的DDD分层架构，只是采用了领域模型和接口分离原则的普通三层架构。它的缺点在于除了数据访问外，没有将其他具体的技术依赖从业务逻辑层中完全分离。

三、DDD分层详解

DDD分层（领域驱动设计分层）明确地将业务逻辑层分成了应用层（服务层）和领域层两部分。它将数据访问和其他接口的具体技术实现部分统一到了基础设施层。关于DDD分层的演变，我们可以发现总是在努力寻求一种更优秀的划分方式，以更好地满足业务需求并降低技术实现的复杂性。

四、架构的趋势

未来的架构趋势将以业务逻辑为核心，更加重视业务逻辑的实现。会将业务逻辑层的具体依赖划分到一个层次进行统一管理。将会更加重视降低解决方案内的依赖性，而非解决方案间的代码复用。共享层和实现层的分离将会越来越多地体现在各种架构设计中，例如洋葱型架构。我们希望大家能对.NET分层架构有更深入的理解。以上所述就是本文的全部内容了，希望大家喜欢。