如何運用領域驅動設計 - 工作單元

来源:https://www.cnblogs.com/uoyo/archive/2020/01/01/12129344.html
-Advertisement-
Play Games

在上一篇 《如何運用領域驅動設計 - 存儲庫》 的文章中，我們講述了有關倉儲的概念和使用規範。倉儲為聚合提供了持久化到本地的功能，但是在持久化的過程中，有時一個聚合根中的各個領域對象會分散到不同的資料庫表裡面；又或者是一個用例操作需要操作多個倉儲；而這些操作都應該要麼同時成功，要麼同時失敗，因此就需... ...


目錄

新年伊始，祝大家喜樂如意，愛和幸福“鼠”不盡！♫. ♪~♬.♩♫~

概述

在上一篇 《如何運用領域驅動設計 - 存儲庫》 的文章中，我們講述了有關倉儲的概念和使用規範。倉儲為聚合提供了持久化到本地的功能，但是在持久化的過程中，有時一個聚合根中的各個領域對象會分散到不同的資料庫表裡面；又或者是一個用例操作需要操作多個倉儲；而這些操作都應該要麼同時成功，要麼同時失敗，因此就需要為這一系列操作提供事務的支持，而事務管理就是由工作單元來提供的。在上一篇中，可能已經提到了工作單元，但是僅僅是一筆帶過，現在我們就來詳細的探究該如何更好的來實現工作單元。（文章的代碼片段都使用的是C#,案例項目也是基於 DotNet Core 平臺）。

直接看東西

在上一篇文章中，已經為大家提供了一個Github的Demo。如果已經下載過該Demo的同學，您現在直接進行Pull就可以獲得最新的版本了；如果還沒有下載該Demo的同學也可以戳下方的跳轉鏈接獲取。

GitHub 地址，點擊直達喲

在這裡我們可以先來看一下，該項目的應用代碼是什麼樣子：

[HttpPost]
public ActionResult<string> Add()
{
    //使用倉儲來處理聚合
    _itineraryRepository.Add(
        new Itinerary(
            "奧特曼",
            "賽文奧特曼",
            "傑克奧特曼",
            "佐菲奧特曼",
            "泰羅奧特曼"));

    _itineraryRepository.Add(
        new Itinerary(
            "蓋亞奧特曼",
            "戴拿奧特曼",
            "阿古茹奧特曼",
            "迪迦奧特曼", ""));

    return "success";
}

[HttpGet]
public ActionResult<long> Get()
{
    var count = _itineraryRepository.GetCount();
    return count;
}

這是在Aspnet Core的Controller中的代碼，也就是對外提供的Api。可以看到我們僅僅只是通過倉儲的調用就完成了所有的操作。（ps:原諒我該演示api沒有遵循restful風格(￣▽￣)"，還有就是那些奧特曼。。。）。

您可能會說，這裡沒有做操作，那肯定是在 ItineraryRepository 裡面做了手腳。好吧，下麵我們來看看該倉儲的實現。

public class ItineraryRepository
        : EFRepository<UowAppDbContext, Itinerary, Guid>
{
    public void Add(Itinerary itinerary) => DbContext.Set<Itinerary>().Add(itinerary);
}

是的，它也只有這麼一點點代碼。而作為後期的業務擴展和維護，我們只需要完善我們的Itinerary聚合（為它擴展行為和增加實體或值對象）以及ItineraryRepository倉儲（為它添加對外檢索意圖的方法）就可以了。

這種做法的好處可能您很快就能發現：在我們代碼中處處都是關於領域對象的操作，儘可能的避免其它基礎構建或功能支持組件來干擾程式。除了代碼量的減少之外，它也讓可讀性有著明顯的提高，如果在此基礎上能夠構建出明確而乾凈的聚合根，那麼您的程式將具備更高的可擴展性。

好吧，回到我們今天的主題：工作單元。其實上面的代碼就是對倉儲中工作單元的巧妙運用，它其實在後面默默的支持著程式的正常運轉，這是在調用層面上我們完全感覺不到它的存在而已。下麵就為您介紹它是怎麼工作和實現的。

什麼是工作單元

按照國際管理呢，這一章節都是解讀有關原著《領域驅動設計:軟體核心複雜性應對之道》 中的解釋。但是！！！有關工作單元的概念在書里並沒有被明確的提及到。所以為了證明我們確確實實是在前人的基礎理念上來實踐，而不是胡編亂造自己隨便弄了一個概念出來。我特地去找了另外一本較為權威的領域驅動設計教材：《領域驅動設計模式、原理與實踐》 。在該書中對工作單元的解釋如下：

事務管理主要與應用程式服務層有關。存儲庫只與使用聚合根的單一集合的管理有關，而業務用例可能會造成對多個類型聚合的更新。事務管理是由工作單元處理的。工作單元模式的作用是保持追蹤業務任務期間聚合的所有變化。一旦所有的變化都已發生，則之後工作單元會協調事務中持久化存儲的更新。如果在將變更提交到數據存儲的中途出現了問題，那麼要確保不損壞數據完整性的話，就要回滾所有的變更以確保數據保持有效的狀態。

其實上文的話真的很好理解（相對於原著而言(￣y▽,￣)╭ ）。首先我們可以得到的第一個結論：事務管理其實是應用服務層乾的事。第二個結論：事務的協調管理都是由工作單元來負責的

所以，我們千萬不能因為工作單元和倉儲有聯繫就將它放置在領域層裡面：事務的提供往往是由資料庫管理程式來提供的，而這一類組件我們一般將它們放置在基礎構架層，而領域層可以依賴於基礎構架層，所以千萬要註意，保持您的領域層足夠乾凈，不要讓其它的東西干擾它，也更不要將事務處理這類東西放到了您的領域層來。（這一點，您會在後期MiCake<米蛋糕>的使用中看到詳細的案例）。

如何實現工作單元

實現工作單元，就是要實現倉儲中的事務操作。您可能已經看到過有些實現Repository的框架，它的寫法是註入一個unitOfWork,然後從uow中提取一個倉儲，然後再用倉儲來完成聚合根的持久化操作。類似的代碼就像這樣：

var yourRepository = uow.GetRepository<yourRepository>();
yourRepository.Add(yourEntity);

uow.Commit();

這樣做沒有一點點的問題，而且是對工作單元和倉儲模式的完美實現。uow工作單元中維持了一個事務，從該工作單元中創建的每一個倉儲都可以獲得該事務，倉儲完成了自己的操作之後，工作單元使用Commit方法告訴事務管理器，該事務完成。

夏目去參加了妖怪的聚會，一回到家，貓咪老師就發現了它沾染了妖怪的味道

夏目友人帳
當倉儲的操作沾染上了工作單元的事務，它也就受到了事務的管理

如果您喜歡這種實現模式，可以參考 threenine的Threenine.Data項目。

懶的模式

其實在剛開始，為 MiCake(米蛋糕) 選取工作單元實現方案的時候，我也打算採用這種方式。但是在思考了一天之後，我還是放棄了。因為我發現這種模式在完成每一次倉儲操作的時候，必須要從工作單元中去獲取。在Aspnet Core中，不得不在Controller中註入工作單元對象，然後再從該對象裡面去獲取倉儲。這顯然削弱了依賴註入所為我們提供的依賴閱讀性（原本在構造函數中，我能看出我需要註入的是A倉儲，但是現在我看到的只有工作單元）。

其實最重要的一點就是：我太懶啦 o_o ....。 為什麼每次都要去多寫一個uow.GetXXXXX()。每使用一個倉儲就要多寫一次獲取語句，我就不能好好的只使用倉儲嗎？ 所以在這個想法的強烈刺激下，我選取了另外的實現方法。

接下來，就讓我們來實現最開始演示代碼中的工作單元吧。哦，對了，忘記說了，無論是演示的Github Demo還是本次的博文，我們都選取了Entity Framework Core來作為數據持久組件。所以有些小伙伴會說，那我使用Dapper或者原生的ADO怎麼辦？ 其實思路都是一樣的，您也可以在看了EFCore的版本後，自己寫出對應的工作單元版本。如果有機會的話，歡迎在Github的Demo上直接添加，就可以提交供更多的同學參考啦。

實現思路

  • 找出當前資料庫持久組件中具有事務特征的對象（比如在EF中就是DbContext）
  • 創建一個容器去容納這些對象
  • 工作單元就是該容器的實現，它掌管了這些事務對象，並對外公佈了提交事務的方法
  • 工作單元管理器負責了對工作單元的創建工作

腦袋裡有了這些還比較模糊的交互對象之後，我們可以來想一下一個倉儲完成添加聚合根的操作是怎麼樣的：

  • 在訪問該API之前：使用工作單元管理器創建一個工作單元
  • 訪問API中的倉儲時候：構造一個事務特征對象，並開啟一個事務
  • 事務開啟完成之後：將該事務特征對象嘗試放入到當前工作單元
  • 倉儲事務操作完成後：調用工作單元的提交方法，完成事務的提交，保證倉儲的數據一致。
  • 事務完成後：釋放上面的各個對象

雖然步驟好像有5步，但總結下來，就是將具有事務的對象放置到工作單元中，讓它去負責提交。對！就是這麼簡單，該方法與上面那種從工作單元中獲取倉儲的方法想法，它是往工作單元中提交。所以，我們此時可以構造出一個偽代碼出來，大致理解它的實現：

    //1、使用工作單元管理器創建一個工作單元
    using (var uow = unitOfWorkManager.Create())
    {
        //2、構造事務特征對象，開啟事務並註冊到工作單元
        RegisteTransactonFeature(DbContext);
        //3、執行倉儲中的內容
        DbContext.Set<Itinerary>().Add(itinerary)
        //4、工作單元保存提交
        uow.SaveChanges();
        //5、dispose
    }

至少到目前，我們可以抽象出上面的各個對象了。
您也可以先自己嘗試著想一想，每個對象介面應該實現什麼功能（方法）。

//首先是事務特征對象，它提供了事務的基本Commit和Rollback方法
public interface ITransactionFeature
{
    public bool IsCommit { get; }
    public bool IsRollback { get; }

    void Commit();
    Task CommitAsync(CancellationToken cancellationToken = default);
    void Rollback();
    Task RollbackAsync(CancellationToken cancellationToken = default);
}

//然後是事務特征容器，它具有增加刪除事務特征對象的方法
public interface ITransactionFeatureContainer
{
    void RegisteTranasctionFeature(string key, ITransactionFeature TransactionFeature);
    ITransactionFeature GetOrAddTransactionFeature(string key, ITransactionFeature TransactionFeature);
    ITransactionFeature GetTransactionFeature(string key);
    void RemoveTransaction(string key);
}

//接下來是工作單元，它實現了事務特征容器，並且對外提供提交的方法
public interface IUnitOfWork : ITransactionFeatureContainer
{
    Guid ID { get; }
    bool IsDisposed { get; }

    void SaveChanges();
    Task SaveChangesAsync(CancellationToken cancellationToken = default);
    void Rollback();
    Task RollbackAsync(CancellationToken cancellationToken = default);
}

//最後是工作單元管理器，它提供了創建工作單元的方法
public interface IUnitOfWorkManager : IUnitOfWokrProvider, IDisposable
{
    IUnitOfWork Create();
}

落地代碼

在構建出介面之後，我們就可以寫出具體的實現類了。首先是實現工作單元（UnitOfWork）對象。（由於具體代碼實現較多，講解部分只選取了核心部分，完整代碼可以參考Github的項目）

public class UnitOfWork : IUnitOfWork
{
    private readonly Dictionary<string, ITransactionFeature> _transactionFeatures;

    public UnitOfWork()
    {
        _transactionFeatures = new Dictionary<string, ITransactionFeature>();
    }

    //往容器中添加事物特征對象
    public virtual ITransactionFeature GetOrAddTransactionFeature(
        [NotNull]string key,
        [NotNull] ITransactionFeature transcationFeature)
    {
        if (_transactionFeatures.ContainsKey(key))
            return _transactionFeatures.GetValueOrDefault(key);

        _transactionFeatures.Add(key, transcationFeature);
        return transcationFeature;
    }

    //對外提供的保存方法，執行該方法時調用容器內所有事物特征對象的Commit方法
    public virtual void SaveChanges()
    {
        foreach (var transactionFeature in _transactionFeatures.Values)
        {
            transactionFeature.Commit();
        }
    }
}

接下來就是與ORM框架關聯最深的事務特征對象的實現了，由於我們選取了EF，所以此處應該實現EF版本的事務特征對象：

public class EFTransactionFeature : ITransactionFeature
{
    private IDbContextTransaction _dbContextTransaction;
    private DbContext _dbContext;

    public EFTransactionFeature(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    //設置事務
    public void SetTransaction(IDbContextTransaction dbContextTransaction)
    {
        _isOpenTransaction = true;
        _dbContextTransaction = dbContextTransaction;
    }

    public void Commit()
    {
        if (IsCommit)
            return;

        IsCommit = true;

        //EF 事務的提交
        _dbContext.SaveChanges();
        _dbContextTransaction?.Commit();
    }
}

建立好了這兩個對象之後，其實我們只需要一個流轉過程就可以實現工作單元了。這個流程就是將事務特征對象添加到工作單元中，但是我們應該在什麼時候將它添加進去呢？看過第一版Github代碼的小伙伴可能知道，在倉儲調用的時候就可以完成該操作。當時在第一版中，我們的實現代碼是這樣的：

public class EFRepository
{
    protected IUnitOfWorkManager UnitOfWorkManager { get; private set; }
    protected DbContext DbContext { get; private set; }

    public EFRepository(IUnitOfWorkManager unitOfWorkManager, DbContext dbContext)
    {
        UnitOfWorkManager = unitOfWorkManager;
        DbContext = dbContext;
    }

    public void Add(TAggregateRoot aggregateRoot)
    {
        RegistUnitOfWork(DbContext);

        DbContext.Set<TAggregateRoot>().Add(aggregateRoot);
    }

    private void RegistUnitOfWork(DbContext dbContext)
    {
        string key = $"EFTransactionFeature - {dbContext.ContextId.InstanceId.ToString()}";
        unitOfWork.ResigtedTransactionFeature(key, new EFTransactionFeature(DbContext));
    }
}

在每一次進行倉儲操作的時候，都調用了一個RegistUnitOfWork的方法，來完成事務特征對象和工作單元的流轉工作。但是很快您就能發現問題：EFRepository是我們實現的一個基類，以後所有的倉儲操作都繼承該類來完成操作，那不是每擴展一個方法，我都要在該方法中寫一句註冊代碼？如果我忘記寫了怎麼辦。還有一點，該註冊過程並沒有開啟一個事務，那麼事務是怎麼來的呢？

那麼怎麼才能避免用戶每一次都要去顯示調用註冊呢，而是讓用戶在不知不覺中就完成了該操作。所以我們得思考在每一個方法中，用戶都一定會寫的代碼是什麼，然後在該代碼上下手。可能您已經想到了，DbContext！！！是的，每一個方法里，用戶都會去寫DbContext，所以我們可以在他獲取DbContext的時候就完成註冊操作。所以，優化後的代碼就是這樣的：

public class EFRepository
{
    public virtual TDbContext DbContext
    {
        get => _dbContextFactory.CreateDbContext();
    }

    public void Add(TAggregateRoot aggregateRoot)
    {
        DbContext.Set<TAggregateRoot>().Add(aggregateRoot);
    }
}

而該_dbContextFactory的實現就更簡單了，他要完成的任務就是註冊到工作單元並且開啟事務。


internal class UowDbContextFactory<TDbContext>
{
    private readonly IUnitOfWorkManager _uowManager;

    public UowDbContextFactory(IUnitOfWorkManager uowManager)
    {
        _uowManager = uowManager;
    }

    public TDbContext CreateDbContext()
    {
        AddDbTransactionFeatureToUow(currentUow, DbContext);

        return wantedDbContext;
    }

    private void AddDbTransactionFeatureToUow(IUnitOfWork uow, TDbContext dbContext)
    {
        string key = $"EFCore - {dbContext.ContextId.InstanceId.ToString()}";
        var efFeature = uow.GetOrAddTransactionFeature(key, new EFTransactionFeature(dbContext));

        if (IsFeatureNeedOpenTransaction(uow, efFeature))
        {
            var dbcontextTransaction = dbContext.Database.BeginTransaction();
            efFeature.SetTransaction(dbcontextTransaction);
        }
    }

    private bool IsFeatureNeedOpenTransaction(IUnitOfWork uow, EFTransactionFeature efFeature)
    {
        return !efFeature.IsOpenTransaction;
    }
}

dbContext.Database.BeginTransaction是EF為我們提供的手動開啟事務的方法。如果您嘗試實現另外ORM版本的工作單元，想一下在該ORM中是怎麼開啟的事務。

此時，我們就已經實現了工作單元的流轉了，那麼還有一個問題就是：我們怎麼預設去實現一個工作單元，而不是每一次都需要手動去開啟並提交。

AspNet Core為我們提供了很好的攔截方法。第一種方法： 我們可以在中間件中完成，因為所有的請求都要穿過中間件，我們可以在方法到API之前就開啟事務，等API訪問結束後就提交事務。第二種方法： 通過IActionFilter等周期介面來完成。本案例選取了第一種實現方法，您也可以根據您自己的愛好選取自己的實現方式。

缺陷

到這裡我們已經實現了像上面Demo版本的工作單元，但是該工作單元其實還有許多特性沒有實現：

  • 一個業務操作（一個API）中沒有創建多個工作單元的能力
  • 目前事務的操作來源於EF Core的支持，如果項目存在多種數據訪問方式（比如一個EF，一個ADO），它們之間如何依靠工作單元來完成事務
  • 沒有識別什麼時候需要開啟工作單元，如果一個操作僅僅需要獲取數據，其實我們是不需要開啟工作單元的

不過如果您的項目僅僅使用了一種ORM框架並且只需要開啟一個工作單元，那麼可以嘗試使用該實現。

在實現MiCake真正的工作單元中，我嘗試了很多方法來解決上面的問題。在後面的文章中，您也會看到MiCake真正的工作單元。

附上一個當時寫工作單元的手記（￣︶￣）↗
手記

總結

本來這篇文章不打算寫在《如何運用領域驅動設計》這個系列的，但是後來糾結了一下，還是納入了該系列。由於該篇文章是實現工作單元的，所以代碼量就比較大，希望不會給您造成閱讀上的困難。下一篇的文章，是一個談了很久的問題————持久化值對象，現在終於是時候該解決它了。在本次Demo中您看到的聚合根Itinerary所有的屬性都是string，很顯然這是不符合常理的，所以在下一次就要讓它成為真正的領域對象。（ps:改成真正的領域對象後，感覺都可以單體DDD應用落地了呢。（￣︶￣）↗醒醒！少年。）為了您不錯過下一篇文章的內容，您也可也點擊博客園右上角的關註，這樣就能及時收到更新了喲。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Pycharm 報錯 Environment location directory is not empty 解決
    新電腦clone項目後發現Project Interpreter無法配置, New environment 選擇後無法應用, 滑鼠懸停在Location 提示 Environment location directory is not empty . 原因是項目push時, 項目下的venv文件夾也 ...
  • crm業務流程圖(精簡版)
    crm業務的流程圖,都是比較精簡的內容,後面有機會的話會繼續擴展 ...
  • 聊聊多線程那一些事兒 之 五 async.await深度剖析
    前面已經講解了task的運行、阻塞、同步、延續操作、取消等！今天我們就專門來聊聊關於async/await的那一些事，分析其實現原理，通過該文章你也該對async的使用還有更加清晰的理解 ...
  • C# IO流與文件讀寫學習筆記
    本筆記摘抄自：https://www.cnblogs.com/liyangLife/p/4797583.html，記錄一下學習過程以備後續查用。 一、文件系統 1.1文件系統類的介紹 文件操作類大都在System.IO命名空間里，FileSystemInfo類是所有文件系統類的基類。FileInfo ...
  • DataReader類型化數據讀取與裝箱性能研究
    你應當知道的ORM的底層細節，DataReader高效使用的姿勢。 ...
  • C# compare different Encoding pattern between UTF8 and UTF32 based on Md5
    I had validated that different encoding mode can generate different result,they are not identical. Besides,the File.ReadAllBytes may based on UTF8 bec ...
  • 使用ASP.NET Core 3.x 構建 RESTful API - 4.1 面向外部的Model
    Entity Framework Core 使用的 Entity Model 是用來表示資料庫裡面的記錄的。 Entity Framework Core 使用的 Entity Model 是用來表示資料庫裡面的記錄的。 而面向外部的 model 則表示了要傳輸的東西。這類 model 有時候叫做 D ...
  • 到底什麼是.NET?
    ​.NET 概念比較龐大，本文只討論基礎知識,只用簡單語言描述。 我們是NET程式員，但是我們有沒有思考過到底什麼是.NET ？ 官方定義 .NET是微軟推出來的一個致力於敏捷開發的軟體框架。 大概2000年年左右，微軟推出了.NET 標準規範，既然有了標準就等於開發時候定義介面一樣，需要東西去實現 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類