这里引用Uncle Bob的定义：
软件架构是指，设计软件的人为软件赋予的形状，这个形状是指系统如何被划分为组件(Components)，各个组件如何排列（Arrangement），组件之间如何沟通（Communication）。
个人认为，一个工程由多个项目组成，项目中之间存在依赖关系。软件的架构即工程中所有关系的集合。
一种架构思想：
1.区别于传统架构自下而上的垂直结构，Clean Architecture是洋葱型的结构，只存在一个核心层，依赖关系单向流动。
2.区别于传统架构核心层依赖于数据层、设施层，Clean Architecture反转了依赖关系，数据层、设施层依赖于核心层。
所以(包含于引用层的)数据层应优先编写，构建数据获取代码，其次编写核心层业务类型，数据操作逻辑。由此核心层不受数据获取的限制，使数据库来源类型等维护成本更小。
简单的Console App Demo，包括使用自建的中介者对象实现以及MediatR实现
在WebAPI中使用MediatR，最大的改变是将原本注入到controller的依赖分散到了MediatR消息的处理方法中
传统的依赖注入如下图
使用MediatR后，MediatR作为抽象的一层将依赖进一步根据具体逻辑分散
而接口则变得非常简洁，即
1.发送MediatR消息
2.获得结果
3.返回结果
在MediatR消息的处理方法中，当然也可以通过注入MediatR来再次发送消息，即嵌套的调用。最大程度得分离逻辑来降低逻辑上的耦合
...
using MediatR;
using Application.Exceptions;
using Application.Item.Models;
using Data.RepositoryInterfaces;
using Domain.BaseInterfaces;
using Domain.Entities;
namespace WebApp.Controllers
{
[ApiController]
public class ItemController : ControllerBase
{
private readonly IMediator _mediator;
public ItemController(IMediator mediator)
{
_mediator = mediator;
}
[HttpGet]
[Route("")]
public async Task<ActionResult> Get(int itemId)
{
var result = await _mediator.Send(new GetItem(id, userid));
if (result == null) return NotFound();
return Ok(result);
}
}
}
namespace Application.Item.Queries
{
public class GetItem : IRequest<ItemViewModel>
{
public GetItem(int itemId, string userId)
{
UserId = userId;
ItemId = itemId;
}
public string UserId { get; }
public int ItemId { get; }
}
public class GetItemHandler : IRequestHandler<GetItem, ItemViewModel>
{
private readonly IMediator _mediator;
private readonly IItemRepository _itemRepository;
public GetItemHandler(
IMediator mediator,
IItemRepository itemRepository
)
{
_mediator = mediator;
_itemRepository = itemRepository;
}
public async Task<ItemViewModel> Handle(GetItem arg, CancellationToken cancellationToken)
{
var item = await _itemRepository.Get()
.Where(i => i.Id == arg.ItemId)
.Select(i => new
{
Id = i.Id,
Name = i.Name,
}).SingleOrDefaultAsync();
if (item == null)
throw new NotFoundException(arg.ItemId.ToString(), nameof(Domain.Entities.Item));
var companyUser = await _mediator.Send(new GetCompanyUser(arg.UserId, item.CompanyId));
bool isCompanyUser = companyUser != null;
return new ItemViewModel(){
ItemId = item.Id,
ItemName = item.Name,
IsCompanyUser = isCompanyUser
};
}
}
public class GetItemPreProcessor : IRequestPreProcessor<GetItem>
{
private readonly IMediator _mediator;
public GetItemPreProcessor(
IMediator mediator)
{
_mediator = mediator;
}
public Task<ItemViewModel> Process(GetItem request, CancellationToken cancellationToken)
{
return await _mediator.Send(new InsertItemViewRecord(request));
}
}
}
namespace Application.Item.Commands
{
//implement InsertItemViewRecord
}
Demo主要流程如下图
中介者模式即对象通过中介者交互而非直接进行。
中介者模式让原本类之间的依赖转移到为了中介者与类间，由此在很大程度上降低程序的耦合度，并大大简化类之间的通信。
中介者类似消息的处理中心，对象向中介者发送请求，中介者分发请求至对应目标。获得目标响应后返回至发起者。
1.程序随功能增多产生复杂的依赖关系，某一方法可能分别依赖不同层级的对象
2.类间的通信、调用流程由于多对多的关系变得繁琐
3.由于类间的相互引用而产生高耦合的代码
以WebApi工程为例，最上层的controller只依赖于中介者对象，中介者对象依赖于业务逻辑。
1.根据中介者的位置进行分割，此时中介者作为controller和业务逻辑之间的分隔起到解耦的作用。上层的controller与下层的业务逻辑始终只与中介者交互，两部分即消息的发送和接收者可以独立的修改，controller的替换或者更新的工作量也就大大减少。
2.在我们对所有的逻辑都尽可能地进行分割的前提下，通过于中介者交互获得某一逻辑片段的响应，组合后完成复杂逻辑。
原本的复杂逻辑可能依赖于多个下层方法，分隔后复杂逻辑只依赖于中介者。
原本依赖的多个下层方法现在分布在各个逻辑片段中，由此，下层方法的改动只对这些逻辑片段产生影响。
3.以复杂逻辑为例，中介消息的接收者只表明调用各个逻辑的顺序以及组合方式。逻辑片段及其依赖的下层方法的修改只要保证自身的返回内容正确，符合请求目的，就不会对其他的所依赖的对象产生影响
有的朋友可能说了，我只要写一个巨大的类，把所有的业务逻辑的方法都放进去，让所有的controller都依赖于这个类，那我是不是也实现了中介者模式？
从结构上来说，这个类也是起到了中介者的角色。但是随着业务增加，中介者对象变得臃肿庞大。
其次这个巨大的类相当于对所有的下层方法产生了依赖，每次使用这个类时，都需要将所有的依赖注入，与依赖注入的目的相违背。
而MediatR在一定程度上解决了这个问题。MediatR提供了简洁且功能丰富的中介者对象
并将依赖向外部分散，依赖注入到细致的下层逻辑中
.NET中的中介者模式实现，一种进程内消息传递框架，提供了中介者对象
MediatR支持以同步或异步的形式进行请求/响应，支持消息的单播/多播
MediatR在WebApi中的位置处于Application与Presentation/Controller之间，请求进入后发送通过MediatR消息，消息处理方法中调用Application
由此，MediatR作为Presentation/Controller和Application的中间连接件，前者只对MediatR产生依赖，而MediatR只对后者产生依赖
首先就是两个依赖关系不一样 理想状态下是presentation只对mediator中介者产生依赖 如果是service直接注入的话 通常情况下不可能只注入一个 presentation就会产生多个引用 增加两者之间的耦合
MediatR把presentation和service分隔开来 这样两个部分的修改变更就更简单
优势是MediatR能分散所有的依赖 降低耦合
弊端是中介者成了程序不能分割的一部分 所以他必须要可靠高效
| 功能 | 通过MediaR调用 |
|---|---|
| 调用方法的前后进行额外处理 | 通过IPipelineBehavior实现类似中间件的功能,通过IRequestPreProcess,IRequestpostProcess来实现为某一方法调用前后附上额外运行的代码 |
| 调用方法触发运行一个或多个代码段 | 通过INotification实现消息的单播/多播 |
| 捕捉异常 | 通过IRequestExceptionHandler,IRequestExceptionAction处理执行方法中产生的异常,运行额外代码 |
通过重写MediatR.PublishCore方法来实现自定义的发布策略
默认发布策略是遍历所有消息的handlers, 逐一执行