eShopOnWeb

eShopOnWeb

https://www.cnblogs.com/sheng-jie/p/9616675.html

构建现代Web应用

1.引言

eShopOnWeb是基于ASP.NET Core构建，官方创建这样一个示例项目的目的，我想无非以下几点：

推广ASP.NET Core

指导利用ASP.NET Core如何进行架构设计

普及架构设计思想

eShopOnWeb 与另外一个eShopOnContainers互相补充。eShopOnContainers是基于微服务和容器技术的应用程序架构，支持多重部署。而eShopOnWeb相较于它就简单的多，其是基于传统Web应用开发，仅支持单一部署。

本文就简单梳理下自己的所学所得。

2.MPA Or SPA

eShopOnWeb的示例项目中包含两个Web项目，一个是基于MVC创建的MPA多页面应用，一个是基于Razor创建的SPA单页面应用。在此之间我该如何选择呢？

是否需要丰富的交互行为？

是否足够的前端技术积累？

是否主要通过API进行交互？

决策表：Mpa or Spa

1. 架构设计
   
   eShopOnWeb中应用了DDD和整洁架构的部分思想，值得了解一下。

3.1 架构原则

关注点分离：简称SOP。在分层架构设计中，关注点分离是核心设计思想，每一层独自负责不同的职责。从架构上讲，可以通过将核心业务与基础设施和用户界面逻辑分离来实现。该原则旨在避免紧耦合，又可确保各个模块独立发展。

封装：封装的是什么？是对象的状态和行为。外部对象无需关注其内部的实现机制。

在类中，通过使用访问修饰符来限制外部的访问来实现封装。 如果外部想要操纵对象的状态，它应该通过定义良好的函数（或属性设置器）来实现，而不是直接访问对象的私有状态。

而不同模块之间通过公开定义良好的接口进行方法调用，来实现封装。以隔离内部的实现机制。通过封装来确保应用程序间不同部分之间的隔离，正确使用封装有助于在应用程序设计中实现松耦合和模块化。

依赖倒置：简称DIP。高层模块不应该依赖低层模块，均应该依赖与抽象；抽象不应该依赖于细节；细节应该依赖于抽象。DIP是构建松耦合应用的关键部分，从而确保应用程序模块化，更易于测试和维护。 通过遵循DIP，可以应用依赖注入。

显式依赖：方法和类应明确指定所需的协作对象（依赖）以确保正常运行。简单来说，对于类而言，提供明确的构造函数（即在构造函数参数中指定该类需要正常工作所需的依赖对象），以便调用者正确传参以正确实例化对象。

单一职责：简称SRP。SRP作为面向对象设计的原则之一，也适用于架构原则。其与SOP类似。它强调对象应该只有一个责任，他们只应该仅有一个改变的理由。换言之，对象应该改变的唯一情况是它的职责需要被更新。遵守该原则，可以编写松耦合和模块化的应用。因为大量的新的行为都应该创建新类去实现，而不是添加到已经存在的类中。添加新类永远比修改一个类安全，因为尚无代码依赖于新类。

在复杂的大型应用中，可以将SRP应用到分层应用的各个层。展现职责应保留在UI项目中，而数据访问职责应保留在基础设施项目中， 业务逻辑应该保留在应用程序核心项目中。如此，即易于测试又可以独立于其他职责持续演化。

该原则的更高级应用，就是微服务了。每个微服务负责独立的职责。

摒弃重复：当出现重复时，应该实施重构。避免当功能改进时，需要同时修改多个部分。

透明持久化：要求可以轻松切换持久化技术，而实现持久化无感知（透明持久化）。

限界上下文：该概念是DDD战略设计的一部分，通过限界上下文来划分领域，作为领域的显式边界，为领域提供上下文语境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。

3.2. 传统分层架构和整洁架构

传统的分层架构是大家所熟知的三层架构。

传统三层架构

三层架构示例

这样的架构的缺点是：

依赖关系由上至下，不易解耦

不易测试，需要测试数据库

那如何解决三层架构的问题呢，借助【依赖倒置原则】。

DDD的分层架构思想和整洁架构中都是借助【依赖倒置原则】实现层与层之间强依赖关系的解耦。我们来看下整洁架构：

整洁架构——洋葱视图

从该洋葱视图中我们可以看到：

依赖关系由外而内。

处于核心的是实体和接口，不依赖任何其他项。其次是领域服务，仅依赖实体和接口，也相对独立。它们统称为应用程序内核。

应用程序内核之外是基础架构层和展现层，彼此也不一定依赖。

由于应用程序内核不依赖于基础设施层，所以可以很容易编写单元测试。

单元测试位置

由于UI层也不直接依赖于基础设施层，所以我们可以轻松置换基础设施层的实现（比如使用内存数据库），以进行集成测试。

集成测试位置

整洁架构——水平视图

下面我们就来看看eShopOnWeb是如何应用整洁架构的。

1. 项目结构
   
   首先我们看下模板架构的项目结构。
   
   eShopOnWeb Solution

从上图来看其项目结构十分简单，简单的三层，加上三个测试项目。

三层对应：

ApplicationCore：领域层

Infrastructure：基础设施层

Web/WebRazorPages：展现层

DDD使用的传统分层架构

其实该项目架构是DDD经典四层架构，只不过其将应用层集成到展现层中去了。

Web应用服务

4.1 基础设施层

主要提供通用的基础服务和持久化。

Infrastructure

从上图的代码结构我们可以看出：

在Data文件夹下定义了用于持久化的商品目录数据库上下文CatalogContext和泛型仓储EfRepository。

Identity文件夹下定义了身份数据库上下文的。

Logging文件夹定义了一个日志适配器。

Services定义了一个通用的邮件发送基础服务。

4.2. 领域层

领域层是一个项目的核心，用来定义业务规则并实现。其主要用来实体、值对象、聚合、仓储、领域服务和领域事件等。

ApplicationCore

从上图来看：

Entities文件夹下定义了三个聚合根和相关的实体及值对象。

Exceptions文件夹定义了公共的异常。

Interfaces文件夹定义了系列接口。

Services文件夹定义了两个领域服务。

Specifications文件夹下是实现的规约模式。

4.2.1. 聚合根的相关实现

这里我们来看下聚合根的相关定义和实现。

///抽象的聚合根空接口

public interface IAggregateRoot

{ }

//所有的实体基类

public class BaseEntity

{

public int Id { get; set; }

}

//购物车聚会根

public class Basket : BaseEntity, IAggregateRoot

{

public string BuyerId { get; set; }

private readonly List _items = new List();

public IReadOnlyCollection Items => _items.AsReadOnly();

public void AddItem(int catalogItemId, decimal unitPrice, int quantity = 1)
{
    if (!Items.Any(i => i.CatalogItemId == catalogItemId))
    {
        _items.Add(new BasketItem()
        {
            CatalogItemId = catalogItemId,
            Quantity = quantity,
            UnitPrice = unitPrice
        });
        return;
    }
    var existingItem = Items.FirstOrDefault(i => i.CatalogItemId == catalogItemId);
    existingItem.Quantity += quantity;
}

}

从这个实现中我们可以学习到：

通过定义一个空的接口IAggregateRoot，要求所有的聚会根来实现它。

这样做的体现了什么思想：

面向接口编程

约定大于配置

依赖注入

通过定义一个BaseEntity，要求所有的实体继承它。

为什么这样做？

因为实体的特征是具有唯一的身份标识，所以通过在父类来定义Id属性来实现。这也就是层超类型的实现方式。

这样做有什么缺点？

因为所有实体的主键类型不一定都是int类型，所以这个基类型最好改成泛型。

Basket聚合根中将Items定位为Readonly，是为了封装集合，避免子项被其他地方更改。

4.2.2. 仓储的相关实现

仓储是用来透明持久化领域对象的。

public interface IRepository where T : BaseEntity

{

T GetById(int id);

T GetSingleBySpec(ISpecification spec);

IEnumerable ListAll();

IEnumerable List(ISpecification spec);

T Add(T entity);

void Update(T entity);

void Delete(T entity);

}

public interface IAsyncRepository where T : BaseEntity

{

Task GetByIdAsync(int id);

Task<List> ListAllAsync();

Task<List> ListAsync(ISpecification spec);

Task AddAsync(T entity);

Task UpdateAsync(T entity);

Task DeleteAsync(T entity);

}

从以上代码我们可以学到两点：

面向接口编程

职责分离，同步异步接口分离。

4.2.3. 领域服务相关实现

领域服务用来实现业务逻辑的。

public interface IOrderService

{

Task CreateOrderAsync(int basketId, Address shippingAddress);

}

public class OrderService : IOrderService

{

private readonly IAsyncRepository _orderRepository;

private readonly IAsyncRepository _basketRepository;

private readonly IAsyncRepository _itemRepository;

public OrderService(IAsyncRepository basketRepository,

IAsyncRepository itemRepository,

IAsyncRepository orderRepository)

{

_orderRepository = orderRepository;

_basketRepository = basketRepository;

_itemRepository = itemRepository;

}

public async Task CreateOrderAsync(int basketId, Address shippingAddress)

{

var basket = await _basketRepository.GetByIdAsync(basketId);

Guard.Against.NullBasket(basketId, basket);

var items = new List();

foreach (var item in basket.Items)

{

var catalogItem = await _itemRepository.GetByIdAsync(item.CatalogItemId);

var itemOrdered = new CatalogItemOrdered(catalogItem.Id, catalogItem.Name, catalogItem.PictureUri);

var orderItem = new OrderItem(itemOrdered, item.UnitPrice, item.Quantity);

items.Add(orderItem);

}

var order = new Order(basket.BuyerId, shippingAddress, items);

await _orderRepository.AddAsync(order);

}

从以上代码我们可以学习到：

依赖注入

领域服务负责实现真正的业务逻辑

4.3. 应用层和展现层

如上面所阐述，在示例项目中应用层和展现层合二为一。应用层负责展现层与领域层之间的协调，协调业务对象来执行特定的应用程序。

1. 面向切面编程（AOP）
   
   eShopOnWeb中也提到了AOP，介绍了在ASP.NET Core中如何应用过滤器来进行AOP，比如：身份验证、模型验证、输出缓存和错误处理等。
   
   通过过滤器和请求管道执行

执行顺序

1. 简明DDD
   
   在eShopOnWeb中，也对DDD的概念，是否使用，何时使用，何时不用，都略有介绍。这里就摘录一二，当然也可以参考我之前的写的DDD理论学习系列。

结论

DDD首先是一个方法论，其注重于领域的合理建模，分为战略建模和战术建模。

如果你不知道你需要它，那么你可能不需要它。

如果你不知道到DDD用于解决什么问题，那么你可能没有遇到这些问题。

DDD倡导者也经常指出其仅适用于大型项目 （>6个月）。

相关概念

DDD是用来对真实世界系统或流程的建模。

使用DDD时，你需要和领域专家紧密合作，领域专家能够解释真实的系统该如何运行。在和领域专家的交流中确定通用语言，其主要用来描述系统中的一些概念。而之所以是通用，是因为不管是开发人员还是领域专家都应能够读懂。而通用语言描述的概念将构成面向对象设计的基础。其体现在代码中的理想状态是代码即设计。

战术

值对象：不可变。

实体：具有唯一标识符可变。

聚会根：在DDD中，用来表示整体与部分的关系，聚合是将相关联的领域对象进行显式分组，来表达整体的概念（也可以是单一的领域对象）。比如将表示订单与订单项的领域对象进行组合，来表达领域中订单这个整体概念。

仓储：一种持久化的模式，用于隔离具体持久化措施，实现透明持久化。

工厂：用于对象的创建。

服务：应用服务和领域服务。领域服务负责业务逻辑，应用服务用于表达业务用例和用户故事。

战略

限界上下文：来为领域提供上下文语境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。

上下文映射图：限界上下文之间的关联关系。

6. 应用测试

在eShopOnWeb中，还示例了三个测试项目，来指导我们合理的进行测试。

单元测试、集成测试和功能测试的区别

1. 总结
   
   总体而言，示例项目简单容易理解，也主要是为了便于推广和演示。但里面涉及的知识点并没有想象的那么简单，从架构原则到设计和应用，每一个环节都包含不简单的知识体系。

所以等什么呢？结合示例项目和官方文档使用 ASP.NET Core 和 Azure 构建新式 Web 应用程序开始学习吧，相信你也会收获颇丰。