在《當我們在討論CQRS時，我們在討論些神馬》中，我們討論了當使用CQRS的過程中，需要關心的一些問題。其中與CQRS關聯最為緊密的模式莫過於Event Sourcing了，CQRS與ES的結合，為我們構造高性能、可擴展系統提供了基本思路。本文將介紹
Kanasz Robert在《Introduction to CQRS》中的示例項目Diary.CQRS。

獲取Diary.CQRS項目

該項目為Kanasz Robert為了介紹CQRS模式而寫的一個測試項目，原始項目可以通過訪問《Introduction to CQRS》來獲取，由於項目版本比較舊，沒有使用nuget管理程序包等，導致下載以後並不能正常運行，我下載了這個項目，升級到Visual Studio 2017，重新引用了StructMap框架（使用nuget），移除了Web層報錯的代碼，並上傳到博客園，可以從這裏下載：Diary.CQRS.rar

Diary.CQRS項目簡介

Diary.CQRS項目的場景為日記本管理，提供了新增、編輯、刪除、列表等功能，整個解決方案分為三個項目：

• Diary.CQRS：核心項目，完成了EventBus、CommandBus、Domain、Storage等功能，也是我們分析的重點。
• Diary.CQRS.Configuration：服務配置，通過ServiceLocator類進行依賴注入、服務查找功能。
• Diary.CQRS.Web：用戶界面，MVC項目。

這是一個很好的入門項目，功能簡單、結構清晰，概念覆蓋全面。如果CQRS是一個城堡，那麼Diary.CQRS則是打開第一重門的鑰匙，接下來讓我們一起推開這扇門吧。

Diary.CQRS.Web

運行項目，最先看到的是一個Web頁面，如下圖：

很簡單，只有一個Add按鈕，當我們點擊以後，會進入添加的頁面：

我們填上一些內容，然後點擊Save按鈕，就會返回到列表頁，我們可以看到已添加的條目：

然後我們進行編輯操作，點擊列表中的Edit按鈕，跳轉到編輯頁面：

雖然頁面中显示的是Add，但確實是Edit頁面。我們編輯以後點擊Save按鈕，然後返回列表頁即可看到編輯后的內容。

在列表頁中，如果我們點擊Delete按鈕，則會刪除改條目。

到此為止，我們已經看到了這個項目的所有頁面，一個簡單的CURD操作。我們繼續看它的代碼（在HomeController中）。

Index：列表頁面

public ActionResult Index()
{
    ViewBag.Model = ServiceLocator.ReportDatabase.GetItems();
    return View();
}

通過ServiceLocator定位ReportDatabase，並從ReportDatabase中獲取所有條目。

Add：新增頁面

public ActionResult Add()
{
    return View();
}

[HttpPost]
public ActionResult Add(DiaryItemDto item)
{
    ServiceLocator.CommandBus.Send(new CreateItemCommand(Guid.NewGuid(), item.Title, item.Description, -1, item.From, item.To));
    return RedirectToAction("Index");
}

兩個方法：

• Add()方法，處理Get請求，返回新增視圖；
• Add(DiaryItemDto item)方法，接收DiaryItemDto參數，處理Post請求，創建併發送CreateItemCommand命令，然後返回到Index頁面

Edit：編輯頁面

public ActionResult Edit(Guid id)
{
    var item = ServiceLocator.ReportDatabase.GetById(id);
    var model = new DiaryItemDto()
    {
        Description = item.Description,
        From = item.From,
        Id = item.Id,
        Title = item.Title,
        To = item.To,
        Version = item.Version
    };
    return View(model);
}

[HttpPost]
public ActionResult Edit(DiaryItemDto item)
{
    ServiceLocator.CommandBus.Send(new ChangeItemCommand(item.Id, item.Title, item.Description, item.From, item.To, item.Version));
    return RedirectToAction("Index");
}

仍然是兩個方法：

• Edit(Guid id)方法，接收Guid作為參數，並從ReportDatabase中獲取數據，構建dto對象返回給頁面
• Edit(DiaryItemDto item)方法，接收DiaryItemDto對象，處理Post請求，接收到請求以後根據dto對象創建ChangeItemCommand命令，然後返回到Index頁面

Delete：刪除操作

public ActionResult Delete(Guid id)
{
    var item = ServiceLocator.ReportDatabase.GetById(id);
    ServiceLocator.CommandBus.Send(new DeleteItemCommand(item.Id, item.Version));
    return RedirectToAction("Index");
}

對於刪除操作來說，它沒有視圖頁面，接收到請求以後，先獲取該記錄，創建併發送DeleteImteCommand命令，然後返回到Index頁面

題外話：對於改變數據狀態的操作，使用Get請求是不可取的，可能存在安全隱患

通過上面的代碼，你會發現所有的操作都是從ServiceLocator發起的，通過它我們能夠定位到CommandBus和ReportDatabase，從而進行相應的操作，我們在接下來會介紹ServiceLocator類。

Diary.CQRS.Configuration

Diary.CQRS.Configuration 項目中定義了ServiceLocator類，這個類的作用是完成IoC容器的服務註冊、服務定位功能。例如我們可以通過ServiceLocator獲取到CommandBus實例、獲取ReportDatabase實例。

服務註冊

ServiceLocator使用StructureMap作為依賴注入框架，提供了服務註冊、服務導航的功能。ServiceLocator類通過靜態構造函數完成對服務註冊和服務實例化工作：

static ServiceLocator()
{
    if (!_isInitialized)
    {
        lock (_lockThis)
        {
            ContainerBootstrapper.BootstrapStructureMap();
            _commandBus = ObjectFactory.GetInstance<ICommandBus>();
            _reportDatabase = ObjectFactory.GetInstance<IReportDatabase>();
            _isInitialized = true;
        }
    }
}

首先調用ContainerBootstrapper.BootstrapStructureMap()方法，這個方法裡面包含了對將服務添加到容器的代碼；然後使用容器創建CommandBus和ReportDatabase的實例。

• CommandBus：命令總線，對應Command操作，用來發送命令，程序中需要定義相應的命令處理器，從而完成具體的操作。
• ReportDatabase：報表數據庫，對應Query操作，用來獲取數據。

ServiceLocator的重要之處在於對外暴露了兩個至關重要的實例，分別處理CQRS中的Command和Query。

為什麼沒有Event相關操作呢？到目前為止我們還沒有涉及到，因為對於UI層來說，用戶的意圖都是通過Command表示的，而數據的狀態變化才會觸發Event。

Diary.CQRS

在ServiceLocator中定義了獲取CommandBus和ReportDatabase的方法，我們順着這兩個對象繼續分析。

CommandBus

在基於消息的系統設計中，我們常會看到總線的身影，Command也是一種消息，所以使用總線是再合適不過的了。CommandBus就是我們在Diary.CQRS項目中用到的一種消息總線。

在Diary.CQRS中，它被定義在Messaging目錄，在這個目錄下面，還有與Event相關的EventBus，我們稍後再進行介紹。

CommandBus實現ICommandBus接口，ICommandBus接口的定義如下：

public interface ICommandBus
{
    void Send<T>(T command) where T : Command;
}

它只包含了Send方法，用來將命令發送到對應的處理程序。

CommandBus是ICommand的實現，具體代碼如下：

public class CommandBus:ICommandBus
{
    private readonly ICommandHandlerFactory _commandHandlerFactory;

    public CommandBus(ICommandHandlerFactory commandHandlerFactory)
    {
        _commandHandlerFactory = commandHandlerFactory;
    }

    public void Send<T>(T command) where T : Command
    {
        var handler = _commandHandlerFactory.GetHandler<T>();
        if (handler!=null)
        {
            handler.Execute(command);
        }
        else
        {
            throw new Exception();
        }
    }
}

在CommandBus中，顯式依賴ICommandHandlerFactory類，通過構造函數進行注入。那麼 _commandHandlerFactory 的作用是什麼呢？我們在Send方法中可以看到，通過 _commandHandlerFactory 可以獲取到與Command對應的CommandHandler（命令處理程序），在程序的設計上，每一個Command都會有一個對應的CommandHandler，而手工判斷類型、實例化處理程序顯然不符合使用習慣，此處採用工廠模式來獲取命令處理程序。

當獲取到與Command對應的CommandHandler后，調用handler的Execute方法，執行該命令。

截止目前為止，我們又接觸了三個概念：CommandHandlerFactory、CommandHandler、Command：

• CommandHandlerFactory：命令處理程序工廠，通過GetHandler方法獲取到與命令對應的處理程序
• CommandHandler：命令處理程序，用於執行對應的命令
• Command：命令，描述用戶的意圖、並包含與意圖相關的數據

CommandHandlerFactory

使用簡單工廠模式，用來獲取與命令對應的處理程序。它的代碼在Utils文件夾中，它的作用是提供一種獲取Handler的方式，所以它只能作為工具存在。

接口定義如下：

public interface ICommandHandlerFactory
{
    ICommandHandler<T> GetHandler<T>() where T : Command;
}

只有GetHandler一個方法，它的實現是 StructureMapCommandHandlerFactory，即通過StructureMap作為依賴注入框架來實現的，代碼也比較簡單，這裏不再貼出來了。

Command和CommandHandler

命令是代表用戶的意圖、並包含與意圖相關的數據，比如用戶想要添加一條數據，這便是一個意圖，於是就有了CreateItemCommand，用戶要在界面上填寫添加操作必須的數據，於是就有了命令的屬性。

關於命令的定義如下：

public interface ICommand
{
    Guid Id { get; }
}

public class Command : ICommand
{
    public Guid Id { get; private set; }
    public int Version { get; set; }

    public Command(Guid id, int version)
    {
        Id = id;
        Version = version;
    }
}

• ICommand接口：包含Id屬性，這個Id表示Command對應聚合的Id。聚合是領域驅動開發（DDD）的概念，表示一組強關聯的領域對象，而對聚合中狀態的變更，只能通過聚合根（AggregateRoot）來完成。

• Command類：實現了ICommand接口，並增加了Version屬性，用來標記當前操作對應的聚合跟的版本。

  為什麼要有版本的概念的？因為當使用ES模式的時候，數據庫中的數據都是事件產生的數據鏡像，保存了某個時間點的數據快照，如果要獲取到最新的數據，則需要通過加載該聚合根對應的所有Event來回放到最新狀態。如果引入版本的概念，每一個Event對應一個版本，而景象中的數據也有一個版本，在進行回放的時候，可以僅加載高版本的Event進行回放，節省了系統資源，並提高了運行效率。

命令處理程序，它的作用是處理與它相對應的命令，處理CQRS的核心，接口定義如下：

public interface ICommandHandler<TCommand> where TCommand : Command
{
    void Execute(TCommand command);
}

它接收command作為參數，執行該命令的處理邏輯。每一個命令都有一個與之對應的處理程序。

我們再重新梳理一下流程，首先用戶要新增一個數據，點擊保存按鈕后，生成CreateItemCommand命令，隨後這個命令被發送到CommandBus中，CommandBus通過CommandHandlerFactory找到該Command的處理程序，此時在CommandBus的Send方法中，我們有一個Command和CommandHandler，然後調用CommandHandler的Execute方法，即完成了該方法的處理。至此，Command的處理流程完結。

CreateItemCommand和CreateItemCommandHandler

我們來看一下CreateItemCommand的代碼：

public class CreateItemCommand : Command
{
    public string Title { get; internal set; }
    public string Description { get; internal set; }
    public DateTime From { get; internal set; }
    public DateTime To { get; internal set; }

    public CreateItemCommand(Guid aggregateId, string title,
        string description, int version, DateTime from, DateTime to)
        : base(aggregateId, version)
    {
        Title = title;
        Description = description;
        From = from;
        To = to;
    }
}

它繼承自Command基類，繼承后即擁有了Id和Version屬性，然後又定義了幾個其它的屬性。它只包含數據，與該命令對應的處理程序叫做CreateItemCommandHandler，代碼如下：

public class CreateItemCommandHandler : ICommandHandler<CreateItemCommand>
{
    private IRepository<DiaryItem> _repository;

    public CreateItemCommandHandler(IRepository<DiaryItem> repository)
    {
        _repository = repository;
    }

    public void Execute(CreateItemCommand command)
    {
        if (command == null)
        {
            throw new Exception();
        }
        if (_repository == null)
        {
            throw new Exception();
        }
        var aggregate = new DiaryItem(command.Id, command.Title, command.Description, command.From, command.To);
        aggregate.Version = -1;
        _repository.Save(aggregate, aggregate.Version);
    }
}

這才是我們要分析的核心，在Handler中，我們看到了Repository，看到了DiaryItem聚合：

• IRepository ：倉儲類，代表數據的儲存方式，通過倉儲能夠進行數據操作
• DiaryItem：領域對象，聚合根，所有數據狀態的變更只能通過聚合根來修改

在上面的代碼中，由於是新增，所以聚合的版本為-1，然後調用倉儲的Save方法進行保存。我們繼續往下扒，看看倉儲和聚合的實現。

Repository

對於Repository的定義，仍然先看一下接口中的定義，代碼如下：

public interface IRepository<T> where T : AggregateRoot, new()
{
    void Save(AggregateRoot aggregate, int expectedVersion);
    T GetById(Guid id);
}

在倉儲中只有兩個方法：

• Save(AggregateRoot aggregate, int expectedVersion)：保存期望版本的聚合根
• GetById(Guid id)：根據聚合根Id獲取聚合根

關於IRepository的實現，代碼在Repository.cs中，我們拆開來進行介紹：

private readonly IEventStorage _eventStorage;
private static object _lock = new object();

public Repository(IEventStorage eventStorage)
{
    _eventStorage = eventStorage;
}

首先是它的構造函數，強依賴IEventStorage，通過構造函數注入。EventStorage是事件的儲存倉庫，有個更為熟知的名字EventStore，我們稍後進行介紹。

public T GetById(Guid id)
{
    IEnumerable<Event> events;
    var memento = _eventStorage.GetMemento<BaseMemento>(id);
    if (memento != null)
    {
        events = _eventStorage.GetEvents(id).Where(e => e.Version >= memento.Version);
    }
    else
    {
        events = _eventStorage.GetEvents(id);
    }
    var obj = new T();
    if (memento != null)
    {
        ((IOriginator)obj).SetMemento(memento);
    }
    obj.LoadsFromHistory(events);
    return obj;
}

GetById(Guid id)方法通過Id獲取一個聚合對象，獲取一個聚合對象有以下幾個步驟：

• 首先會從EventStorage中獲取到該聚合的快照（memento的翻譯為記憶碎片、紀念品、備忘錄，用來聚合對象的快照）。

• 加載Event列表，加載到的事件列表將用來做事件回放。

  如果獲取到快照的話，則加載版本高於該快照版本的事件列表，如果沒有獲取到快照，則加載全部事件列表。此處在上面已經介紹過，通過快照的方式保存聚合對象，在獲取數據時可以減少重放事件的數量，起到提高加載速度的作用。

• 實例化聚合根，對應代碼中的var obj = new T();。
• 從快照中設置聚合根的狀態。在獲取到快照以後，如果快照不為空，則調用聚合根的SetMemento方法設置為快照中的狀態，SetMemento方法定義在IOriginator接口中，聚合根需要實現該接口。

• 加載歷史事件，完成重放。完成這個步驟以後，聚合根將更新到最新狀態。

通過這幾個步驟以後，我們得到了一個最新狀態的聚合根對象。

public void Save(AggregateRoot aggregate, int expectedVersion)
{
    if (aggregate.GetUncommittedChanges().Any())
    {
        lock (_lock)
        {
            var item = new T();
            if (expectedVersion != -1)
            {
                item = GetById(aggregate.Id);
                if (item.Version != expectedVersion)
                {
                    throw new Exception();
                }
            }
            _eventStorage.Save(aggregate);
        }
    }
}

Save方法，用來保存一個聚合根對象。在這個方法中，參數expectedVersion表示期望的版本，這裏約定-1為新增的聚合根，當聚合根為新增的時候，會直接調用EventStorage中的Save方法。

關於expectedVersion參數，我們可以理解為對併發的控制，只有當expectedVersion與GetById獲取到的聚合根對象的版本相同時才能進行保存操作。

在介紹Repository類的時候，我們接觸了兩個新的概念：EventStorage和AggregateRoot，接下來我們分別進行介紹。

AggregateRoot

AggregateRoot是聚合根，他表示一組強關聯的領域對象，所有對象的狀態變更只能通過聚合根來完成，這樣可以保證數據的一致性，以及減少併發衝突。應用到EventSourcing模式中，聚合根的好處也是很明顯的，我們所有對數據狀態的變更都通過聚合根完成，而每次變更，聚合根都會生成相應的事件，在進行事件回放的時候，又通過聚合根來完成歷史事件的加載。由此我們可以看到，聚合根對象應該具備生成事件、重放事件的能力。

我們來看看聚合根基類的定義，在Domain文件夾中：

public abstract class AggregateRoot : IEventProvider{
    // ......
}

首先這是一個抽象類，實現了IEventProvider接口，該接口的定義如下：

public interface IEventProvider
{
    void LoadsFromHistory(IEnumerable<Event> history);
    IEnumerable<Event> GetUncommittedChanges();
}

它定義了兩個方法，我們分別進行說明：

• LoadsFromHistory()方法：加載歷史事件，還原聚合根的最新狀態，我們在Repository中已經用過這個方法。
• GetUncommittedChanges()方法：獲取未提交的事件。一個命令可能造成聚合根發生多次更改，每次更改都會產生一個事件，這些事件被暫時的保存在聚合根對象中，通過該方法可以獲取到未提交的事件列表。

為了實現這個接口，聚合根中定義了 List<Event> _changes對象，用來臨時存儲所有未提交的事件，該對象在構造函數中進行初始化。

AggregateRoot中對於該事件的實現如下：

public void LoadsFromHistory(IEnumerable<Event> history)
{
    foreach (var e in history)
    {
        ApplyChange(e, false);
    }
    Version = history.Last().Version;
    EventVersion = Version;
}

public IEnumerable<Event> GetUncommittedChanges()
{
    return _changes;
}

LoadsFromHistory方法遍歷歷史事件，並調用ApplyChange方法更新聚合根的狀態，在完成更新後設置版本號為最後一個事件的版本。GetUncommittedChanges方法比較簡單，返回對象的_changes事件列表。

接下來我們看看ApplyChange方法，該方法有兩個實現，代碼如下：

protected void ApplyChange(Event @event)
{
    ApplyChange(@event, true);
}

protected void ApplyChange(Event @event, bool isNew)
{
    dynamic d = this;
    d.Handle(Converter.ChangeTo(@event, @event.GetType()));
    if (isNew)
    {
        _changes.Add(@event);
    }
}

這兩個方法定義為protected，只能被子類訪問。我們可以理解為，ApplyChange(Event @event)方法為簡化操作，對第二個參數進行了默認為true的操作，然後調用ApplyChange(Event @event, bool isNew)方法。

在ApplyChange(Event @event, bool isNew)方法中，調用了聚合根的Handle方法，用來處理事件。如果isNew參數為true，則將事件添加到change列表中，如果為false，則認為是在進行事件回放，所以不進行事件的添加。

需要注意的是，聚合根的Handle方法，與EventHandler不同，當Event產生以後，首先由它對應的聚合根進行處理，因此聚合根要具備處理該事件的能力，如何具備呢？聚合根要實現IHandle接口，該接口的定義如下：

public interface IHandle<TEvent> where TEvent:Event
{
    void Handle(TEvent e);
}

這裏可以看出，IHandle接口是泛型的，它只對一個具體的Event類型生效，在代碼上的體現如下：

public class DiaryItem : AggregateRoot,
    IHandle<ItemCreatedEvent>,
    IHandle<ItemRenamedEvent>,
    IHandle<ItemFromChangedEvent>,
    IHandle<ItemToChangedEvent>,
    IHandle<ItemDescriptionChangedEvent>,
    IOriginator
{
    //......
}

最後，聚合根還定義了清除所有事件的方法，代碼如下：

public void MarkChangesAsCommitted()
{
    _changes.Clear();
}

MarkChangesAsCommitted()方法用來清空事件列表。

Event

終於到我們今天的另外一個核心內容了，Event是ES中的一等公民，所有的狀態變更最終都以Event的形式進行存儲，當我們要查看聚合根最新狀態的時候，可以通過事件回放來獲取。我們來看看Event的定義：

public interface IEvent
{
    Guid Id { get; }
}

IEvent接口定義了一個事件必須擁有唯一的Id進行標識。然後Event實現了IEvent接口：

public class Event:IEvent
{
    public int Version;
    public Guid AggregateId { get; set; }
    public Guid Id { get; private set; }
}

可以看到，除了Id屬性外，還添加了兩個字段Version和AggregateId。AggregateId表示該事件關聯的聚合根Id，通過該Id可以獲取到唯一的聚合根對象；Version表示事件發生時該事件的版本，每次產生新的事件，Version都會進行累加。

從而可以知道，在EventStorage中，聚合根Id對應的所有Event中的Version是順序累加的，按照Version進行排序可以得到事件發生的先後順序。

EventStorage

顧名思義，EventStorage是用來存儲Event的地方。在Diary.CQRS中，EventStorage的定義如下：

public interface IEventStorage
{
    IEnumerable<Event> GetEvents(Guid aggregateId);
    void Save(AggregateRoot aggregate);
    T GetMemento<T>(Guid aggregateId) where T : BaseMemento;
    void SaveMemento(BaseMemento memento);
}

• GetEvents(Guid aggregateId)：根據聚合根Id獲取該聚合根的所有事件
• Save(AggregateRoot aggregate)：保存方法，入參為聚合根對象，在實現上則是獲取聚合根中所有未提交的事件，隨後對這些事件進行處理
• GetMemento()：獲取快照
• SaveMemento()：存儲快照

Diary.CQRS中使用InMemory的方式實現了EventStorage，屬性和構造函數如下：

private List<Event> _events;
private List<BaseMemento> _mementoes;
private readonly IEventBus _eventBus;

public InMemoryEventStorage(IEventBus eventBus)
{
    _events = new List<Event>();
    _mementoes = new List<BaseMemento>();
    _eventBus = eventBus;
}

• _events：事件列表，內存中存儲事件的位置，所有事件最終都會存儲在該列表中
• _mementoes：快照列表，用於存儲聚合根的某個事件版本的狀態
• _eventBus：事件總線，用於發布任務

當Event生成后，它並沒有馬上存入EventStorage，而是在Repository显示調用Save方法時，倉儲將存儲權交給了EventStorage，EventStorage是事件倉庫，事件倉儲在存儲時進行了如下操作：

• 獲取聚合根中所有未提交的Event，同時獲取到聚合根當前的版本號
• 遍歷未提交Event列表，根據聚合根版本號自動為Event生成版本號，保持自增長的特性；
• 生成聚合根快照。示例中每3個版本生成一次，並保持到事件倉儲中。
• 將任務添加到事件倉庫中。
• 再次遍歷未提交Event列表，此時將進行任務發布，調用事件總線的Publish方法進行發布。

Save方法的代碼如下：

public void Save(AggregateRoot aggregate)
{
    var uncommittedChanges = aggregate.GetUncommittedChanges();
    var version = aggregate.Version;

    foreach (var @event in uncommittedChanges)
    {
        version++;
        if (version > 2)
        {
            if (version % 3 == 0)
            {
                var originator = (IOriginator)aggregate;
                var memento = originator.GetMemento();
                memento.Version = version;
                SaveMemento(memento);
            }
        }
        @event.Version = version;
        _events.Add(@event);
    }
    foreach (var @event in uncommittedChanges)
    {
        var desEvent = Converter.ChangeTo(@event, @event.GetType());
        _eventBus.Publish(desEvent);
    }
}

至此Event的處理流程就算完結了。此時所有的操作都是在主庫完成的，當事件被發布以後，訂閱了該事件的所有Handler都將會被觸發。

在Diary.CQRS項目中，EventHandler都被用來處理ReportDatabase了。

ReportDatabase

當你使用ES模式時，都存在一個嚴重問題，那就是數據查詢的問題。當用戶進行數據檢索是，必然會使用各種查詢條件，然而無論那種事件倉庫都很難滿足複雜查詢。為了解決此問題，ReportDatabase就顯得格外重要。

ReportDatabase的作用被定義為獲取數據、應對數據查詢、生成報表等，它的結構與主庫不同，可以根據不同的業務場景進行定義。

ReportDatabase的數據不是通過業務邏輯進行更新的，它通過訂閱Event進行更新。在本示例中ReportDatabase實現的很簡單，接口定義如下：

public interface IReportDatabase
{
    DiaryItemDto GetById(Guid id);
    void Add(DiaryItemDto item);
    void Delete(Guid id);
    List<DiaryItemDto> GetItems();
}

實現上，通過內存中維護一個列表，每次接收到事件以後，都對相應數據進行更新，此處不在貼出。

EventHandler、EventHandlerFactory和EventBus

在上文中已經介紹過Event，而針對Event的處理，實現邏輯上與Command非常相似，唯一的區別是，命令只可以有一個對應的處理程序，而事件則可以有多個處理程序。所以在EventHandlerFactory中獲取處理程序的方法返回了EventHandler列表，代碼如下：

public IEnumerable<IEventHandler<T>> GetHandlers<T>() where T : Event
{
    var handlers = GetHandlerType<T>();

    var lstHandlers = handlers.Select(handler => (IEventHandler<T>)ObjectFactory.GetInstance(handler)).ToList();
    return lstHandlers;
}

在EventBus中，如果一個事件沒有處理程序也不會引發錯誤，如果有一個或多個處理程序，則會以此調用他們的Handle方法，代碼如下：

public void Publish<T>(T @event) where T : Event
{
    var handlers = _eventHandlerFactory.GetHandlers<T>();
    foreach (var eventHandler in handlers)
    {
        eventHandler.Handle(@event);
    }
}

總結

Diary.CQRS是一個典型的CQRS+ES演示項目，通過對該項目的分析，我們能了解到Command、AggregateRoot、Event、EventStorage、ReportDatabase的基礎知識，了解他們相互關係，尤其是如何進行事件存儲、如何進行事件回放的內容。

另外，我們發現在使用CQRS+ES的過程中，項目的複雜度增加了很多，我們不可避免的要使用EventStore、Messaging等架構，從而影響那些不了解CQRS的團隊成員的加入，因此在應用到實際項目的時候，要適可而止，慎重選擇，避免過度設計。

由於這是一個示例，項目代碼中存在很多不夠嚴謹的地方，大家在學習的過程中應進行甄別。

由於本人的知識有限，如果內容中存在不準確或錯誤的地方，還請不吝賜教！

【精選推薦文章】

自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

目錄

• 引言
• 控制反轉
• 讀寫分離分庫分表
  • 理論基礎
  • 設計目標
  • 現狀調研
  • 設計思路
  • 實現之過五關斬六將
    • 動態對象
    • 動態模型緩存
    • 數據源移植
    • 查詢表達式樹深度移植
    • 數據合併算法
    • 事務支持
  • 實際使用
• 展望未來

引言

前方硬核警告：全文乾貨11000+字，請耐心閱讀
遙想去年這個時候，差不多剛剛畢業，如今正式工作差不多一年了。Colder開源快速開發框架從上次版本發布至今差不多有三個月了，Github的星星5個版本框架總共也有近800顆，QQ群從最初的一個人發展到現在的500人（吐槽下，人數上限了，太窮開不起SVIP，所以另開了一個，群號在文章末），這都是大家共同發展的結果，本框架能夠幫助到大家鄙人就十分開心。但是，技術是不斷髮展的，本框架也必須適應潮流，不斷升級才能夠與時俱進，在實際意義上提高生產力。本系列框架從原始雛形（鄙人畢業設計）=>.NET45+Easyui=>.NET Core2.1+Easyui=>.NET45+AdminLTE=>.NET Core2.1+AdminLTE，這其中都是根據實際情況不斷升級。例如鄙人最初的畢業設計搭建了框架的雛形（倉儲層不夠完善、界面較簡陋），並不適合實際的生產開發，因此使用Easyui作為前端UI框架（控件豐富，使用簡單），后又由於.NET Core的發展迅速，已經發展到2.0，其基礎類庫組件也相對比較成熟了，因此從.NET45遷移到.NET Core。後來發現Easyui的樣式比較落後，給人一種過時古老的感覺，故而又將前端UI改為基於Bootstrap的AdminLTE，比較成熟主流並且開源。
但是，新的要求又出現了：

• 由於沒有使用IOC導致各個類通過New導致的強耦合問題
• 數據庫大數據量如何處理的問題
  因此，本次版本更新主要就是為了解決上述的問題，即全面使用Autofac作為IOC容器實現解耦以及數據庫讀寫分離分庫分表（Sharding）支持。下面將分別介紹。
  這次更新.NET45版本與.NET Core版本同步更新：

控制反轉

IOC（DI），即控制反轉（依賴注入），相關概念大家應該都知道，並且大多數人應該都已經運用於實際。我就簡單描述下，簡單講就是面向接口編程，通過接口來解除類之間的強耦合，方便開發維護測試。這個概念在JAVA開發中應該比較普遍，因為有Spring框架的正確引導，但是在.NET中可能開發人員的相關意識就沒那麼強，JAVA與.NET我這裏不做評價，但是作為技術人員，天生就是不斷學習的，好的東西當然要學習，畢竟技多不壓身。

在.NET 領域中IOC框架主流有兩個，即Autofac與Unity，這兩個都是優秀的開源框架，經過一番考量后我最終選擇了更加主流的（星星更多）Autofac。

關於Autofac的詳細使用教程請看官方文檔https://autofac.org/，我這裏主要介紹下集成到本框架的思路以及用法。
傳統使用方法通過手動註冊具體的類實現某接口，這種做法顯然不符合實際生產需求，需要一種自動註冊的方式。本框架通過定義兩個接口類：IDependency與ICircleDependency來作為依賴注入標記，所有需要使用IOC的類只需要繼承其中一個接口就好了，其中IDependency是普通注入標記，支持屬性注入但不支持循環依賴，ICircleDependency是循環依賴注入標記，支持循環依賴，實際使用中按需選擇即可。下面代碼就是自動註冊的實現：

var builder = new ContainerBuilder();

var baseType = typeof(IDependency);
var baseTypeCircle = typeof(ICircleDependency);

//Coldairarrow相關程序集
var assemblys = BuildManager.GetReferencedAssemblies().Cast<Assembly>()
    .Where(x => x.FullName.Contains("Coldairarrow")).ToList();

//自動注入IDependency接口,支持AOP
builder.RegisterAssemblyTypes(assemblys.ToArray())
    .Where(x => baseType.IsAssignableFrom(x) && x != baseType)
    .AsImplementedInterfaces()
    .PropertiesAutowired()
    .InstancePerLifetimeScope()
    .EnableInterfaceInterceptors()
    .InterceptedBy(typeof(Interceptor));

//自動注入ICircleDependency接口,循環依賴注入,不支持AOP
builder.RegisterAssemblyTypes(assemblys.ToArray())
    .Where(x => baseTypeCircle.IsAssignableFrom(x) && x != baseTypeCircle)
    .AsImplementedInterfaces()
    .PropertiesAutowired(PropertyWiringOptions.AllowCircularDependencies)
    .InstancePerLifetimeScope();

//註冊Controller
builder.RegisterControllers(assemblys.ToArray())
    .PropertiesAutowired();

//註冊Filter
builder.RegisterFilterProvider();

//註冊View
builder.RegisterSource(new ViewRegistrationSource());

//AOP
builder.RegisterType<Interceptor>();

var container = builder.Build();
DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

AutofacHelper.Container = container;

代碼中有相關註釋，使用方法推薦使用構造函數注入：

框架已在Business層與Web層全面使用DI，Util層、DataRepository層與Entity層不涉及業務邏輯，因此不使用DI。

讀寫分離分庫分表

前面的IOC或許沒啥可驚喜的，但是數據庫讀寫分離分庫分表應該不會讓大家失望。接下來將闡述下框架支持Sharding的設計思路以及具體使用方法。

理論基礎

數據庫讀寫分離分庫分表（以下簡稱Sharding），這並不是什麼新概念，網上也有許多的相關資料。其根本就是為了解決一個問題，即數據庫大數據量如何處理的問題。

當業務規模較小時，使用一個數據庫即可滿足，但是當業務規模不斷擴大（數據量增大、用戶數增多），數據庫最終將會成為瓶頸（響應慢）。數據庫瓶頸主要有三種情況：數據量不大但是讀寫頻繁、數據量大但是讀寫不頻繁以及數據量大並且讀寫頻繁。

首先，為了解決數據量不大但是讀寫頻繁導致的瓶頸，需要使用讀寫分離，所謂讀寫分離就是將單一的數據庫分為多個數據庫，一些數據庫作為寫庫（主庫），一些數據庫作為讀庫（從庫），並且開啟主從複製（實時將寫入的數據同步到從庫中），這樣將數據的讀寫分離后，將原來單一數據庫用戶的讀寫操作分散到多個數據庫中，極大的降低了數據庫壓力，並且打多數情況下讀操作要遠多於寫操作，因此實際運用中大多使用一主多從的模式。

其次，為了解決數據量大但是讀寫不頻繁導致的瓶頸，需要使用分庫分表。其實思想也是一樣的，即分而治之，一切複雜系統都是通過合理的拆分從而有效的解決問題。分庫分表就是將原來的單一數據庫拆分為多個數據庫，將原來的一張表拆分為多張表，這樣表的數據量就將下來了，從而解決問題。但是，拆表並不是胡亂拆的，隨便拆到時候數據都找不到，那還怎麼玩，因此拆表需要按照一定的規則來進行。最簡單的拆表規則，就是根據Id字段Hash后求余，這種方式使用簡單但是擴容很麻煩（絕大多數都需要遷移，工作量巨大，十分麻煩），因此大多用於基本無需擴容的業務場景。後來經過一番研究后，發現可以使用雪花Id（分佈式自增Id）來解決問題，雪花Id中自帶了時間軸，因此在擴容時可以根據時間段來判斷具體的分片規則，從而擴容時無需數據遷移，但是存在一定程度上的數據熱點問題。最後，找到了葵花寶典-一致性哈希，關於一致性哈希的理論我這裏就不獻醜了，相關資料網上一大把。一致性哈希從一定程度上解決了普通哈希的擴容問題與數據熱點問題，框架也支持使用一致性哈希分片規則。

最後，就是大BOSS，大數據量與大訪問量，很簡單隻需要結合讀寫分離與分庫分表即可，下錶是具體業務場景與採用方案的關係
| 數據量\訪問量 | 小 | 大 |
|-|-|-|
|小| 無| 讀寫分離 |
| 大 | 分庫分表 |讀寫分離分庫分表|

設計目標

首先定一個小目標（先賺他一個億）：支持多種數據庫，使用簡單，業務升級改動小。
有了目標就需要調查業界情況，實現Sharding，市面上主要分為兩種，即使用中間件與客戶端實現。

現狀調研

中間件的優點是對客戶端透明，即對於客戶端來講中間件就是數據庫，因此對於業務改動影響幾乎沒有，但是對中間件的要求就很高，目前市面上比較主流成熟的就是mycat，其對MySQL支持比較好，但是對於其他數據庫支持就比較無力（個人測試，沒有深入研究，若有不妥請不要糾結），並且不支持EF，此方案行不通。其它類型數據庫也有對應的中間件，但是都並不如意，自己開發更不現實，因此使用中間件方案行不通。

既然中間件行不通，那就只能選擇客戶端方案了。目前在JAVA中有大名鼎鼎的Sharding-JDBC，了解了下貌似很牛逼，可惜.NET中並沒有Sharding-NET，但是有FreeSql，粗略了解了下是一個比較強大ORM框架，但我的框架原來底層是使用EF的，並且EF是.NET中主流的ORM框架，整體遷移到FreeSql不現實，因此最終沒找到成熟的解決方案。

設計思路

最後終於到了最壞的情況，既沒有完美的中間件方案，又沒有現成的客戶端方案，怎麼辦呢？放棄是不可能的，這輩子都不可能放棄的，終於，內心受到了黨的啟發，決定另起爐灶（既然沒有現成的那就自己早造）、打掃乾淨屋子再請客（重構數據倉儲層，實現Sharding）、一邊倒（堅定目標不改變，不妥協），由於EF支持多種數據庫，已經對底層SQL進行了抽象封裝，因此決定基於EF打造一套讀寫分離分庫分表方案。

數據庫讀寫分離實現：讀寫分離比較簡單，在倉儲接口中已經明確定義了CRUD操作接口，其中增、刪、改就是指寫操作，寫的時候按照具體的讀寫規則找到具體的寫庫進行寫操作即可，讀操作（查數據）按照具體的讀規則找到具體的讀庫進行讀即可。

數據庫分庫分表：分庫還好說，使用不同的數據庫即可，分表就比較麻煩了。首先實現分表的寫操作，可以根據分片規則能夠找到具體的物理表然後進行操作即可，實現比較容易。然後實現分表的讀操作，這個就比較麻煩了，就好比前面的都是斗皇以下的在小打小鬧，而這個卻是斗帝（騎馬），但是，作為一名合格的攻城獅是不怕斗帝的，遇到了困難不要慌，需要冷靜思考處理。前面提到過，解決複雜問題就是一個字“拆”，首先聯表查詢就直接不考慮支持了（大數據量進行笛卡爾積就是一種愚蠢的做法，怎麼優化都沒用，物理數據庫隔絕聯表不現實，實現難度太大放棄）。接下來考慮最常用的方法：分頁查詢、數據篩選、最大值、最小值、平均值、數據量統計，EF中查詢都是通過IQueryable接口實現的，IQueryable中主要包括了數據源（特定表）與關聯的表達式樹Expression，通過考慮將數據源與關聯的表達式樹移植到分表的IQueryable即可實現與抽象表相同的查詢語句，最後將併發多線程查詢分表的數據通過合併算法即可得到最終的實際數據。想法很美好，現實很殘酷，下面為大家簡單闡述下實現過程，可以說是過五關斬六將。

實現之過五關斬六將

動態對象

首先考慮分表的寫操作，傳統用法都有具體的實體類型進行操作，但是分表時，例如Base_UnitTest_0、Base_UnitTest_1、Base_UnitTest_2，這些表全部保存為實體類不現實，因此需要一種非泛型方法，後來在EF的關鍵類DbContext中找到DbEntityEntry Entry(object entity)方法，通過DbEntityEntry可以實現數據的增刪改操作，又注意到傳入參數是object，由此猜測EF支持非泛型操作，即只需要傳入特定類型的object對象也行。例如抽象表是Base_UnitTest，實際需要映射到表Base_UnitTest_0，那麼怎樣將Base_UnitTest類型的對象轉換成Base_UnitTest_0類型的對象？經過查閱資料，可以通過System.Reflection.Emit命名空間下的TypeBuilder在運行時創建動態類型，即可以在運行時創建Base_UnitTest_0類型，該類型擁有與Base_UnitTest完全一樣的屬性（因為表結構完全一樣），創建了需要的類型，接下來只需要通過Json.NET將Base_UnitTest對象轉為Base_UnitTest_0即可。實現到這裏，原以為會順利成功，但是並沒有那麼簡單，EF直接報錯“上下文不包含模型Base_UnitTest_0”，這明顯就是模型的問題了，接下來進入下一關：EF動態模型緩存

動態模型緩存

通常都是通過繼承DbContext重寫OnModelCreating方法來註冊實體模型，這裡有個坑就是OnModelCreating只會執行一次，並最終生成DbCompiledModel然後將其緩存，後續創建的DbContext就會直接使用緩存的DbCompiledModel，由於最初註冊實體模型的時候只有抽象類型Base_UnitTest，所有後續在使用Base_UnitTest_0對象的時候會報錯。為了解決這個問題，需要自己管理DbCompiledModel緩存，實現過程比較麻煩，這裏就不詳細分析了，有興趣的直接看源碼即可。將緩存問題解決后，終於成功的實現了Base_UnitTest_0的增刪改，這時，心裏一喜（有戲）。實現了寫操作（增、刪、改）之後，接下來就是實現查詢了，那麼如何實現查詢呢？EF中查詢操作都是通過IQueryable接口實現的，IQueryable中包括了具體數據表的數據源和關聯的查詢表達式樹，那麼如何將IQueryable < Base_UnitTest >轉換為IQueryable < Base_UnitTest_0 > 並且保留原始查詢語句就成了關鍵問題。

數據源移植

根據經驗，想一舉同時移植數據源與表達式樹應該不現實，實際情況也是如此，移植數據源，通過使用ExpressionVisitor可以找到根數據源，其實是一個ObjectQuery類型，並且在表達式樹中是以ConstantExpression存在，同樣通過ExpressionVisitor則可將原ObjectQuery替換為新的，實現過程省略10000字。

查詢表達式樹深度移植

數據源移植后，別以為就大功告成了，接下來進入一個深坑（最難點），表達式樹移植，經過一番踩坑后發現，表達式樹中的所有節點都是樹狀結構，任何一個查詢（Where、OrderBy、Skip、Take等）在表達式樹中都是以一個節點存在，並且一級扣一級，也就是說你改了數據源沒用，因為數據源只是表達式樹的根節點，下面的所有子節點還都是原來的根節點發的牙，並不能使用，那怎樣才能用新數據源構建與原數據源一樣的表達式樹呢？經過如下分析：IQuryable中的所有操作都是MethodCallExpression一層一層包裹，那麼我從外到內剝開方法，然後再從內到外包裹新的數據源，那不就模擬得一模一樣了嗎？（貌似有戲），想到先進后出腦子里直接就蹦出了數據結構中的棧，強大的.NET當然支持棧了，經過一番操作（奮鬥幾個晚上），此處省略10000字，最終完成IQueryable的移植，即從IQueryable < Base_UnitTest >轉換為IQueryable < Base_UnitTest_0 > 並且保留原始查詢語句。有了分表的IQueryable就能夠獲取分表的數據了，最後需要將獲取的分表數據進行合併。

數據合併算法

分表后的數據合併算法主要參考了網上的一些資料，雖然分庫分表的實現方式各不相同，但是思想都是差不多的，例如需要獲取Count，只需要將各個分表的Count求和即可，最大值只需要所有分表的最大值的最大值即可，最小值只需要所有分表最小值的最小值即可，平均值需要所有分表的和然後除以所有分表的數據條數即可。最後比較麻煩的就是分頁查詢，分頁查詢需要分表排序后獲取前N頁的所有數據（不能直接獲取某一頁的數據，因為不一定就是那一頁），最後將所有表的數據再進行分頁即可。實現到這裏，已經實現了增、刪、改、查了，看似革命已經成功，其實還有最後的大BOSS：事務支持

事務支持

因為分表很可能不在同一個數據庫中，因為普通的單庫事務顯然不能滿足需求，原本框架中已經有分佈式事務支持（多庫事務），這裏需要集成到Sharding中，實現過程省略10000字，最終黃天不負有心人終於實現了。

到這裏，肯定有暴躁老哥坐不住了：你前面BBB那麼多，說得那麼牛逼，到底怎麼用啊？？？，若文章到此為止，估計就是下圖：

鄙人則回復如下：

深夜12點了，放鬆一下，最後介紹如何使用

實際使用

本框架支持數據庫讀寫分離分庫分表（即Sharding），並且支持主流關係型數據庫（SQLServer、Oracle、MySQL、PostgreSQL）,理論上只要EF支持那麼本框架支持。
由於技術原因以及結合實際情況，目前本框架僅支持單表的Sharding，即支持單表的CRUD、分頁、統計（數量、最大值、最小值、平均值），支持跨庫（表分散在不同的數據庫中，不同類型數據庫也支持）。具體如何使用如下：

• Sharding配置
  首先、要進行分庫分表操作，那麼必要的配置必不可少。配置代碼如下：

ShardingConfigBootstrapper.Bootstrap()
    //添加數據源
    .AddDataSource("BaseDb", DatabaseType.SqlServer, dbBuilder =>
    {
        //添加物理數據庫
        dbBuilder.AddPhsicDb("BaseDb", ReadWriteType.ReadAndWrite);
    })
    //添加抽象數據庫
    .AddAbsDb("BaseDb", absTableBuilder =>
    {
        //添加抽象數據表
        absTableBuilder.AddAbsTable("Base_UnitTest", tableBuilder =>
        {
            //添加物理數據表
            tableBuilder.AddPhsicTable("Base_UnitTest_0", "BaseDb");
            tableBuilder.AddPhsicTable("Base_UnitTest_1", "BaseDb");
            tableBuilder.AddPhsicTable("Base_UnitTest_2", "BaseDb");
        }, new ModShardingRule("Base_UnitTest", "Id", 3));
    });

上述代碼中完成了Sharding的配置：
ShardingConfigBootstrapper.Bootstrap()在一個項目中只能執行一次，所以建議放到Application_Start中（ASP.NET Core中的Startup）
AddDataSource是指添加數據源，數據源可以看做抽象數據庫，一個數據源包含了一組同類型的物理數據庫，即實際的數據庫。一個數據源至少包含一個物理數據庫，多個物理數據庫需要開啟主從複製或主主複製，通過ReadWriteType（寫、讀、寫和讀）參數來指定數據庫的操作類型，通常將寫庫作為主庫，讀庫作為從庫。同一個數據源中的物理數據庫類型相同，表結構也相同。
配置好數據源后就可以通過AddAbsDb來添加抽象數據庫，抽象數據庫中需要添加抽象數據表。如上抽象表Base_UnitTest對應的物理表就是Base_UnitTest_0、Base_UnitTest_1與Base_UnitTest_2，並且這三張表都屬於數據源BaseDb。分表配置當然需要分表規則（即通過一種規則找到具體數據在哪張表中）。
上述代碼中使用了最簡單的取模分片規則，
源碼如下：

可以看到其使用方式及優缺點。
另外還有一致性HASH分片規則

雪花Id的mod分片規則

上述的分片規則各有優劣，都實現IShardingRule接口，實際上只需要實現FindTable方法即可實現自定義分片規則。
實際使用中個人推薦使用雪花Id的mod分片規，這也是為什麼前面數據庫設計規範中默認使用雪花Id作為數據庫主鍵的原因（PS，之前版本使用GUID作為主鍵被各種嫌棄，這次看你們怎麼說）

• 使用方式
  配置完成，下面開始使用，使用方式非常簡單，與平常使用基本一致
  首先獲取分片倉儲接口IShardingRepository

IShardingRepository _db = DbFactory.GetRepository().ToSharding();

然後即可進行數據操作：

Base_UnitTest _newData  = new Base_UnitTest
{
    Id = Guid.NewGuid().ToString(),
    UserId = "Admin",
    UserName = "超級管理員",
    Age = 22
};
List<Base_UnitTest> _insertList = new List<Base_UnitTest>
{
    new Base_UnitTest
    {
        Id = Guid.NewGuid().ToString(),
        UserId = "Admin1",
        UserName = "超級管理員1",
        Age = 22
    },
    new Base_UnitTest
    {
        Id = Guid.NewGuid().ToString(),
        UserId = "Admin2",
        UserName = "超級管理員2",
        Age = 22
    }
};
//添加單條數據
_db.Insert(_newData);
//添加多條數據
_db.Insert(_insertList);
//清空表
_db.DeleteAll<Base_UnitTest>();
//刪除單條數據
_db.Delete(_newData);
//刪除多條數據
_db.Delete(_insertList);
//刪除指定數據
_db.Delete<Base_UnitTest>(x => x.UserId == "Admin2");
//更新單條數據
_db.Update(_newData);
//更新多條數據
_db.Update(_insertList);
//更新單條數據指定屬性
_db.UpdateAny(_newData, new List<string> { "UserName", "Age" });
//更新多條數據指定屬性
_db.UpdateAny(_insertList, new List<string> { "UserName", "Age" });
//更新指定條件數據
_db.UpdateWhere<Base_UnitTest>(x => x.UserId == "Admin", x =>
{
    x.UserId = "Admin2";
});
//GetList獲取表的所有數據
var list=_db.GetList<Base_UnitTest>();
//GetIQPagination獲取分頁后的數據
var list=_db.GetIShardingQueryable<Base_UnitTest>().GetPagination(pagination);
//Max
var max=_db.GetIShardingQueryable<Base_UnitTest>().Max(x => x.Age);
//Min
var min=_db.GetIShardingQueryable<Base_UnitTest>().Min(x => x.Age);
//Average
var min=_db.GetIShardingQueryable<Base_UnitTest>().Average(x => x.Age);
//Count
var min=_db.GetIShardingQueryable<Base_UnitTest>().Count();
//事務,使用方式與普通事務一致
using (var transaction = _db.BeginTransaction())
{
    _db.Insert(_newData);
    var newData2 = _newData.DeepClone();
    _db.Insert(newData2);
    bool succcess = _db.EndTransaction().Success;
}

上述操作中表面上是操作Base_UnitTest表，實際上卻在按照一定規則使用Base_UnitTest_0~2三張表，使分片對業務操作透明，極大提高開發效率，基本達成了最初定製的小目標。
具體使用方式請參考單元測試源碼：
“\src\Coldairarrow.UnitTests\DataRepository\ShardingTest.cs”

最後放上簡單的測試圖：300W的表分成三張100W的表後效果

看來功夫沒白費，效果明顯（還不快點贊）

展望未來

結束也是是新的開始，版本後續計劃採用前後端完全分離方案，前端使用vue-element-admin，後端以.NET Core為主，傳統的.NET將逐步停止更新，敬請期待！
文章雖然結束了，但是技術永無止境，希望我的文檔能夠幫助到大家。
深夜碼字，實屬不易，文章中難免會出現一些紕漏，一些觀點也不一定完全正確，還望各位大哥不吝賜教。
最後覺得文檔不錯，請點贊，Github請星星，若有各種疑問歡迎進群交流：
QQ群1:373144077（已滿）
QQ群2:579202910

See You

【精選推薦文章】

智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

帶您來看台北網站建置，台北網頁設計，各種案例分享

廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益