設計模式在業務系統中的應用

来源:https://www.cnblogs.com/88223100/archive/2022/09/20/Application-of-Design-Pattern-in-Business-System.html
-Advertisement-
Play Games

本文的重點在於說明工作中所使用的設計模式，為了能夠更好的理解設計模式，首先簡單介紹一下業務場景。使用設計模式，可以簡化代碼、提高擴展性、可維護性和復用性。有哪些設計模式，這裡就不再介紹了，網上很多，本文只介紹所用到設計模式。 ...


 

 本文的重點在於說明工作中所使用的設計模式，為了能夠更好的理解設計模式，首先簡單介紹一下業務場景。使用設計模式，可以簡化代碼、提高擴展性、可維護性和復用性。有哪些設計模式，這裡就不再介紹了，網上很多，本文只介紹所用到設計模式。
一  線路檢查工具
1  意義
為什麼需要線路檢查工具呢，有以下幾個方面的原因：

  • 每逢大促都需要進行各網路和各行業的線路調整，調整完成之後，是否得到期望狀態，需要檢查確認。

 

  • 上下游應用之間數據的一致性檢查，如果存在不一致，可能會在訂單履行時造成卡單。

 

  • 有些問題發生後，業務同學需要全面檢查一遍線路數據，判斷是否符合預期。

 

  • 各領域之間的數據變更缺乏聯動性，導致資源和線路出現不一致。


為什麼要把線路檢查工具產品化呢，考慮如下：

  • 以前每次大促，都是技術同學現場編寫代碼撈數據給到業務同學，而且因為人員流動性較大，代碼可復用性較低，導致重覆勞動。產品化後，可以方便地傳承下去，避免不必要的重覆勞動。

 

  • 每次因為時間緊急，現場寫的代碼都比較簡單，經常是直接將數據列印到標準輸出，然後複製出來，人工拆分轉成Excel格式；這樣的過程要進行多次，占用太多技術同學的時間。產品化後，解放了技術同學，業務同學可以自己在頁面操作。

 

  • 很多數據檢查，是每次大促都會進行的，業務同學與技術同學之間來回溝通的成本較高。產品化後，可以避免這些耗時耗力的溝通，大家可以把更多的時間放在其他的大促保障工作上。


2  檢查項
根據2020年D11進行的數據檢查，本次共實現8項，下麵列舉了4項，如下：

  • 時效對齊檢查：確保履行分單正常。

 

  • 弱控線路與表達網路一致性：確保履行和路由不會因為線路缺失而卡單。

 

  • 資源映射和編碼映射一致：前者是表達線路時所用，後者是訂單履約時所用，確保表達和履約能夠一致。

 

  • 檢查線路數量：統計現存線路的情況。


好了，瞭解了背景知識，下麵開始介紹所用到的設計模式，以及為什麼要用、怎麼用。
二  設計模式
1  模板方法模式+泛型
上述8項數據檢查工具，大致的處理流程是類似的，如下：

 

 

 針對不同的檢查工具，只有“線路數據檢查”這一步是不一樣的邏輯，其他步驟都是相同的，如果每個檢查工具都實現這麼一套邏輯，必定造成大量的重覆代碼，維護性較差。

模板方法模式能夠很好地解決這個問題。模板方法設計模式包含模板方法和基本方法，模板方法包含了主要流程；基本方法是流程中共用的邏輯，如創建檢查任務，結果輸出等等。

下圖是所實現的模板方法模式的類繼承關係：

 

 

 分析如下：

1）DataCheckProductService介面為對外提供的服務，dataCheck方法為統一的數據檢查介面。


2）AbstractDataCheckProductService是一個抽象類，設定模板，即在dataCheck方法中設定好流程，包括如下：

  • commonParamCheck方法：進行參數合法性檢查，不合法的情況下，直接返回。

 

  • createFileName方法：創建文件名稱。

 

  • createTaskRecord方法：創建檢查任務。

 

  • runDataCheck方法：進行數據檢查，這是一個抽象方法，所有檢查工具都要實現此方法，以實現自己的邏輯。

 

  • uploadToOSS方法：將檢查結果上傳到OSS，便於下載。

 

  • updateRouteTask方法：結束時更新任務為完成。


dataCheck方法為模板方法，runDataCheck方法由各個子類去實現，其他方法是基本方法。還有一些其他方法，是各個檢查工具都需要使用的，所以就放在了父類中。
3）CheckSupplierAndCodeMappingService類、CheckLandingCoverAreaService類和CheckAncPathNoServiceService類為具體的檢查工具子類，必須實現runDataCheck方法。
因為不同檢查項檢的查結果的格式是不一樣的，所以使用了泛型，使得可以相容不同的檢查結果。
簡化的代碼如下：

/**
 * 數據檢查工具產品化對外服務介面
 * @author xxx
 * @since xxx
 * */
public interface DataCheckProductService {
    /**
     * 數據檢查
     * @param requestDTO 請求參數
     * */
  <T> BaseResult<Long> dataCheck(DataCheckRequestDTO requestDTO);
}

/**
 * 數據檢查工具產品化服務
 *
 * @author xxx
 * @since xxx
 * */
public abstract class AbstractDataCheckProductService implements DataCheckProductService {
    /**
     * 數據檢查
     * @param requestDTO 請求參數
     * @return
     * */
    @Override
    public <T> BaseResult<Long> dataCheck(DataCheckRequestDTO requestDTO){
        try{
            //1. 參數合法性檢查
            Pair<Boolean,String> paramCheckResult = commonParamCheck(requestDTO);
            if(!paramCheckResult.getLeft()){
                return BaseResult.ofFail(paramCheckResult.getRight());
            }
            
            //2. 創建導出任務
            String fileName = createFileName(requestDTO);
            RouteTaskRecordDO taskRecordDO = createTaskRecord(fileName, requestDTO.getUserName());

            //3. 進行數據檢查
            List<T> resultList = Collections.synchronizedList(new ArrayList<>());
            runDataCheck(resultList, requestDTO);

            //4. 寫入文件
            String ossUrl = uploadToOSS(fileName,resultList);
            //5. 更新任務為完成狀態
            updateRouteTask(taskRecordDO.getId(),DDportTaskStatus.FINISHED.intValue(), resultList.size()-1,"",ossUrl);

            return BaseResult.ofSuccess(taskRecordDO.getId());
        }catch (Exception e){
            LogPrinter.errorLog("dataCheck-error, beanName="+getBeanName(),e);
            return BaseResult.ofFail(e.getMessage());
        }
    }

     /**
     * 進行數據檢查
     * @param resultList 存放檢查結果
     * @param requestDTO 請求參數
     * @return
     * */
    public abstract <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO);
}

/**
 * 檢查資源映射和編碼映射一致
 * @author xxx
 * @since xxx
 * */
public class CheckSupplierAndCodeMappingService extends AbstractDataCheckProductService{
    @Override
    public <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO){
        //自己的檢查邏輯
    }
}

/**
 * 檢查區域內落地配必須三級全覆蓋
 * @author xxx
 * @since xxx
 * */
public class CheckLandingCoverAreaService extends AbstractDataCheckProductService{
    @Override
    public <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO){
        //自己的檢查邏輯
    }
}

/**
 * 檢查資源映射和編碼映射一致
 * @author xxx
 * @since xxx
 * */
public class CheckAncPathNoServiceService extends AbstractDataCheckProductService{
    @Override
    public <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO){
        //自己的檢查邏輯
    }
}

使用模板方法模式的好處是：

  • 簡化了代碼，每個工具只需要關心自己的核心檢查邏輯，不需要關註前置和後置操作。

 

  • 提高了擴展性，可以方便地增加新的檢查工具。

 

  • 統一的異常捕獲和處理邏輯，子類有異常，儘管往外拋出。


2  策略模式
之所以會用到策略模式，是因為一些檢查工具寫完之後，發現跑出來的結果數據太多，有幾萬、幾十萬等等，一方面，檢查比較耗時，結果文件會很大，下載耗時；另一方面，這麼多數據給到業務同學，他們也很難處理和分析，也許他們只是想看一下總體情況，並不想看具體的到哪個地方的線路。為此，在原先方案設計的基礎上，增加了“統計信息”的選項，讓用戶可以自行選擇“詳細信息”還是“統計信息”，對應到頁面上就是一個單選框，如下：

 

 

 現在增加了一種檢查方式，今後是否還會有其他的檢查方式？完全有可能的。所以得考慮到擴展性，便於後面同學增加新的檢查方式。
此外，還有一種場景也可以使用策略模式，那就是業務系統中有很多業務網路，不同網路之間有一些差異；本次所實現的檢查工具，有幾個涉及到多個網路，今後可能會涉及到所有網路。
綜合以上兩種場景，最合適的就是策略模式了。“詳細信息”和“統計信息”各採用一種策略，不同網路使用不同的策略，既便於代碼理解，又便於後續擴展。
 “詳細信息”和“統計信息”兩種檢查結果的策略類圖如下：

 

 

 解析：

  • CompareModeStrategy對外提供統一的結果處理介面doHandle，策略子類必須實現此介面。

 

  • SupplierAndCodeMappingStatisticsStrategy和SupplierAndCodeMappingDetailStrategy是檢查配送資源和編碼映射一致性的兩種結果信息方式，前者為統計方式，後者為詳細方式。

 

  • LandingCoverAreaStatisticsStrategy和LandingCoverAreaDetailStrategy是檢查落地配覆蓋範圍的兩種結果信息方式，前者為統計方式，後者為詳細方式。

 

  • 那AbstractCompareModeStrategy是乾什麼用的？它是一個抽象類，負責承接所有策略子類共用的一些方法。


簡化的代碼如下：

/**
 * 檢查結果策略對外介面
 * @author xxx
 * @since xxx
 * */
public interface CompareModeStrategy {
    /**
     * 具體操作
     *
     * @param list
     * @param requestDTO
     * @return 結果集
     * */
    <T> List<T> doHandle(List<CompareBO> list, DataCheckRequestDTO requestDTO);
}

/**
 * 策略公共父類
 *
 * @author xxx
 * @since xxx
 * @apiNote 主要是將子類共用方法和成員抽離出來
 * */
public abstract class AbstractCompareModeStrategy implements CompareModeStrategy {
    //子類的共用方法，可以放在此類中
}

/**
 * 檢查落地配覆蓋範圍 詳細信息 策略類
 * @author xxx
 * @since xxx
 * */
public class LandingCoverAreaDetailStrategy extends AbstractCompareModeStrategy{
    @Override
    public <T> List<T> doHandle(List<CompareBO> list, DataCheckRequestDTO requestDTO){
        List<T> resultList = new ArrayList<>();
    //檢查結果處理邏輯
        return resultList;
    }
}

/**
 * 檢查落地配覆蓋範圍 統計信息 策略類
 * @author xxx
 * @since xxx
 * */
public class LandingCoverAreaStatisticsStrategy extends AbstractCompareModeStrategy{
    @Override
    public <T> List<T> doHandle(List<CompareBO> list, DataCheckRequestDTO requestDTO){
        List<T> resultList = new ArrayList<>();
    //檢查結果處理邏輯
        return resultList;
    }
}

/**
 * 檢查配送資源和編碼映射一致 詳細信息 策略類
 * @author xxx
 * @since xxx
 * */
public class SupplierAndCodeMappingDetailStrategy extends AbstractCompareModeStrategy{
    @Override
    public <T> List<T> doHandle(List<CompareBO> list, DataCheckRequestDTO requestDTO){
        List<T> resultList = new ArrayList<>();
    //檢查結果處理邏輯
        return resultList;
    }
}

/**
 * 檢查配送資源和編碼映射一致 統計信息 策略類
 * @author xxx
 * @since xxx
 * */
public class SupplierAndCodeMappingStatisticsStrategy extends AbstractCompareModeStrategy{
    @Override
    public <T> List<T> doHandle(List<CompareBO> list, DataCheckRequestDTO requestDTO){
        List<T> resultList = new ArrayList<>();
    //檢查結果處理邏輯
        return resultList;
    }
}

同樣，不同網路的處理策略類圖如下：

 

 

 代碼與上面類似，就不展示了。
使用策略模式的好處是：

  • 提高代碼擴展性，後續增加別的結果格式或別的網路處理邏輯，可以在不修改其他策略的情況下直接新增。

 

  • 提高代碼可讀性，取代了if...else，條理清晰。

 

  • 不同系列採用不同的策略，策略與策略之間可以嵌套使用，形成策略的疊加效用。


3  工廠模式
工廠模式解決的是bean的生產問題，簡單工廠模式根據入參生產不同的bean，普通工廠模式針對每個bean都構建一個工廠，此兩者各有優劣，看需要。本方案採用的是簡單工廠模式。
之所以使用工廠模式，是因為有太多的bean需要構造，如果在業務邏輯中構造各種bean，則會顯得凌亂和分散，所以需要一個統一生成bean的地方，更好地管理和擴展。
本方案中主要有三類bean需要工廠來生成：

  • 模板方法模式中所用到的子類。

 

  • 檢查結果格式策略中所用到的子類。

 

  • 不同網路處理策略中所用到的子類。


所以，使用三個工廠分別構造這三種類型的bean。另外，因為每個bean主要的功能都在方法中，不涉及類變數的使用，所以可以利用spring容器生成的bean，而不是我們自己new出來，這樣就使得bean可以重覆使用。因此，這裡的工廠只是bean的決策（根據參數決定使用哪個bean），不用自己new了。
三個工廠分別如下：

  • DataCheckProductFatory：由getDataCheckProductService方法根據輸入參數決策使用哪個數據檢查工具。

 

  • CompareModeStrategyFactory：用於決策使用哪種格式輸出，因為將輸出策略分為了2類（詳細信息和統計信息），所以需要傳入兩個參數才能決定使用哪種策略。

 

    • DataCheckNetworkStrategyFactory：用於決策使用哪種網路處理策略，因為將策略分為了2類（4PL網路和其他網路），所以需要傳入兩個參數才能決定使用哪種策略。

       

       

       

       

       這三個工廠的代碼類似，這裡就以CompareModeStrategyFactory為例，簡化的代碼如下：

      /**
 * 比對結果集方式
 * @author xxx
 * @since xxx
 * */
@Service
public class CompareModeStrategyFactory {

    /************************ 詳細結果的bean  **************************/
    @Resource
    private LandingCoverAreaDetailStrategy landingCoverAreaDetailStrategy;
    @Resource
    private SupplierAndCodeMappingDetailStrategy supplierAndCodeMappingDetailStrategy;

    /************************ 統計結果的bean  **************************/
    @Resource
    private LandingCoverAreaStatisticsStrategy landingCoverAreaStatisticsStrategy;
    @Resource
    private SupplierAndCodeMappingStatisticsStrategy supplierAndCodeMappingStatisticsStrategy;

    /**
     * 獲取比對結果的策略
     * */
    public CompareModeStrategy getCompareModeStrategy(DataCheckProductEnum productEnum, DataCompareModeEnum modeEnum){
        CompareModeStrategy compareModeStrategy = null;
        switch (modeEnum){
            case DETAIL_INFO:
                compareModeStrategy = getDetailCompareModeStrategy(productEnum);
                break;
            case STATISTICS_INFO :
                compareModeStrategy = getStatisticsCompareModeStrategy(productEnum);
                break;
            default:;
        }
        return compareModeStrategy;
    }
    /**
     * 獲取 信息信息 策略對象
     * */
    private CompareModeStrategy getDetailCompareModeStrategy(DataCheckProductEnum productEnum){
        CompareModeStrategy compareModeStrategy = null;
        switch (productEnum){
            case CHECK_LANDING_COVER_AREA:
                compareModeStrategy = landingCoverAreaDetailStrategy;
                break;
            case CHECK_SUPPLIER_AND_CODE_MAPPING:
                compareModeStrategy = supplierAndCodeMappingDetailStrategy;
                break;
            default:;
        }
        return compareModeStrategy;
    }
    /**
     * 獲取 統計信息 策略對象
     * */
    private CompareModeStrategy getStatisticsCompareModeStrategy(DataCheckProductEnum productEnum){
        CompareModeStrategy compareModeStrategy = null;
        switch (productEnum){
            case CHECK_LANDING_COVER_AREA:
                compareModeStrategy = landingCoverAreaStatisticsStrategy;
                break;
            case CHECK_SUPPLIER_AND_CODE_MAPPING:
                compareModeStrategy = supplierAndCodeMappingStatisticsStrategy;
                break;
            default:;
        }
        return compareModeStrategy;
    }
}

      使用工廠模式的好處是：

      • 便於bean的管理，所有的bean都在一處創建（或決策）。

       

      • 條理清晰，便於閱讀和維護。


      4  “代理模式”
      這個代理模式是打著雙引號的，因為不是真正的代理模式，只是從實現方式上來說，具有代理模式的意思。為什麼需要用到代理模式？是因為類太多了，業務邏輯分散在各個類中，有的在模板子類中，有的在網路策略中，有的在結果輸出格式策略中，而這些業務邏輯都需要多線程執行和異常捕獲。如果有個代理類，能夠收口這些處理邏輯，只需增加前置多線程處理和後置異常處理即可。
      Java語言中的函數式編程，具備這種能力。所謂函數式編程，是指能夠將方法當做參數傳遞給方法，前面“方法”是業務邏輯，後面“方法”是代理，將業務邏輯傳遞給代理，就實現了統一收口的目的。

      能夠實現此功能的介面有四個，分別是：Consumer、Supplier、Predicate與Function，怎麼使用可以網上查詢。本方案使用的是Consumer，因為它是用來消費的，即需要傳入一個參數，沒有返回值，符合本方案的設計。

      簡化後的代碼如下：

      @Service
public class CheckLandingCoverAreaService extends AbstractDataCheckProductService {
    @Override
    public <T> void runDataCheck(List<T> resultList, DataCheckRequestDTO requestDTO){
        dataCheckUtils.parallelCheckByFromResCodes(requestDTO,requestDTO.getFromResCodeList(),fromResCode->{
            ExpressNetworkQuery query = new ExpressNetworkQuery();
            query.setNs(NssEnum.PUB.getId());
            query.setStatus(StatusEnum.ENABLE.getId());
            query.setGroupNameList(requestDTO.getGroupNameList());
            query.setBrandCodeList(requestDTO.getBrandCodeList());
            query.setFromResCode(fromResCode);
            List<TmsMasterExpressNetworkDO> masterExpressNetworkDOS = tmsMasterExpressNetworkService.queryExpressNetworkTimeList(query);
            startCompareWithAnc(resultList,requestDTO,masterExpressNetworkDOS,fromResCode,solutionCodeMap);
        });
    }
}

@Service
public class DataCheckUtils {
    /**
     * 並行處理每個倉
     * @param requestDTO 請求參數
     * @param fromResCodeList 需要檢查的倉列表
     * @param checkOperation 具體的業務處理邏輯
     * */
    public <T> void parallelCheckByFromResCodes(DataCheckRequestDTO requestDTO, List<String> fromResCodeList, Consumer<String> checkOperation){
        List<CompletableFuture> futureList = Collections.synchronizedList(new ArrayList<>());
        fromResCodeList.forEach(fromResCode->{
            CompletableFuture future = CompletableFuture.runAsync(() -> {
                try{
                    checkOperation.accept(fromResCode);
                }catch (Exception e){
                    LogPrinter.errorLog("parallelCheckByFromResCodes-error, taskId="+requestDTO.getTaskId(),e);
                    recordErrorInfo(requestDTO.getTaskId(),e);
                }
            }, DATA_CHECK_THREAD_POOL);
            futureList.add(future);
        });
        //等待所有線程結束
        futureList.forEach(future->{
            try{
                future.get();
            }catch (Exception e){
                LogPrinter.errorLog("parallelCheckByFromResCodes-future-get-error",e);
            }
        });
    }
}

      可以看出，Consumer所代表的就是一個方法，將此方法作為parallelCheckByFromResCodes方法的一個參數，在parallelCheckByFromResCodes中進行多線程和異常處理，既能統一收口，又大大減少了重覆代碼。
      代理模式的好處是：

      • 統一收口多種不同的業務邏輯，統一做日誌和異常處理。

       

      • 減少重覆代碼，提高了代碼質量。

       

      • 可維護性較強。


      5  其他
      像結果輸出格式策略模式那樣，雖然AbstractCompareModeStrategy沒有實際的業務邏輯，但仍然把它作為一個基類，目的是所有子類共用的邏輯或方法，能夠放在此類中，減少代碼量，提升維護性。

      但是有的時候，不是繼承自同一個基類的子類們，仍然要共用一些邏輯或方法（如parallelCheckByFromResCodes方法），但Java語言限制一個類只能繼承一個基類，怎麼辦呢？簡單的辦法就是把這些共用邏輯或方法放到一個工具類（如DataCheckUtils）中。

三  思考&感悟
在做這個項目的過程中，剛開始沒有很好的設計，也沒有想的很全面，導致代碼改了又改，雖然耽誤點時間，但覺得是值得的。總結以下幾點：

  • 將提升代碼可讀性、可擴展性和可維護性的意識註入到平時的項目中，便於自己，利於他人。如果項目緊急沒時間考慮很多，希望之後有時間時能夠改善和優化。

    • 工作不僅是為了完成任務，更是提升自己的過程。能力要用將來進行時。

 

作者：興亮

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Application-of-Design-Pattern-in-Business-System.html


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

-Advertisement-
Play Games
更多相關文章
  • TP6框架--CRMEB學習筆記：佈置後臺管理框架+配置路由
    這裡給大家分享我在網上總結出來的一些知識，希望對大家有所幫助 最近在研究一個基於TP6的框架CRMEB，這裡分享下我的開發心得 首先在上篇文章中，我們安裝了CRMEBphp介面項目，需要可以看這一篇 TP6框架--CRMEB學習筆記：項目初始化+環境配置 1.獲取項目 這裡是git地址 https: ...
  • antd 批量上傳文件邏輯
    通過 antd 框架的 Upload 控制項，採用手動上傳的方式，先選擇需要上傳的文件（控制文件數量以及大小），再根據所選的文件列表，迴圈上傳，期間通過 Spin 控制項提示上傳中。 ...
  • 如何優化前端性能？
    隨著前端的範疇逐漸擴大，深度逐漸下沉，富前端必然帶來的一個問題就是性能。特別是在大型複雜項目中，重前端業務可能因為一個小小的數據依賴，導致整個頁面卡頓甚至崩潰。本文基於Quick BI（數據可視化分析平臺）歷年架構變遷中性能的排查、解決和總結出的“個性”問題，嘗試總結整個前端層面相對“共性”的問題，... ...
  • 單標簽實現複雜的棋盤佈局
    最近，有群友問我，他們的一個作業，儘量使用少的標簽去實現這樣一個象棋佈局： 他用了 60 多個標簽，而他的同學，只用了 6 個，問我有沒有辦法儘可能的做到利用更少的標簽去完成這個佈局效果。 其實，對於一個頁面的佈局而言，標簽越少不一定是好事，我們在考慮 DOM 的消耗的同時，也需要關註代碼的可讀性， ...
  • CSS Flexbox 佈局
    ⚠️1.1萬長文⚠️ React源碼並非洪水猛獸，知道方法，就可以很輕易地馴服它(=^▽^=)。文章基於最新的React源碼進行調試及閱讀，將以通俗地方式解讀React ...
  • 聊聊秒殺系統的設計（四）
    前言 如果你第一次接觸秒殺，可能還不太理解，庫存100件就賣100件，在資料庫里減到0就好了，這有什麼麻煩的?理論上是這樣，但是具體到業務場景中就沒那麼簡單了。今天就聊聊減庫存的設計，之後以高可用方案來結束秒殺設計的全部內容。 一、秒殺中的減庫存 減庫存操作一般有如下幾個方式： 1.下單減庫存：下單 ...
  • 我的設計模式之旅、14 模板方法模式
    我的設計模式之旅。本節學習模板方法模式。從多個類包含許多相似代碼的問題中思考如何在保持演算法結構完整的情況下去除重覆代碼。介紹了模板方法模式的概念和實現方法。 ...
  • 【設計模式】Java設計模式 - 模板模式
    在模板模式（Template Pattern）中，一個抽象類公開定義了執行它的方法的方式/模板。它的子類可以按需要重寫方法實現，但調用將以抽象類中定義的方式進行。這種類型的設計模式屬於行為型模式。 ...
一周排行
    -Advertisement-
    Play Games
  • C#自增運算符詳解：++i與i++的區別及應用場景
    概述：在C#中，++i和i++都是自增運算符，其中++i先增加值再返回，而i++先返回值再增加。應用場景根據需求選擇，首碼適合先增後用，尾碼適合先用後增。詳細示例提供清晰的代碼演示這兩者的操作時機和實際應用。 在C#中，++i 和 i++ 都是自增運算符，但它們在操作上有細微的差異，主要體現在操作的 ...
  • Taurus.MVC 性能壓力測試（ap 壓測 和 linux 下wrk 壓測）：.NET 版本
    上次發佈了：Taurus.MVC 性能壓力測試（ap 壓測 和 linux 下wrk 壓測）：.NET Core 版本，今天計劃準備壓測一下 .NET 版本，來測試並記錄一下 Taurus.MVC 框架在 .NET 版本的性能，以便後續持續優化改進。 為了方便對比，本文章的電腦環境和測試思路，儘量和... ...
  • 一文讀懂.NET WebAPI中FromRoute、FromQuery、FromBody的關鍵角色與用法
    .NET WebAPI作為一種構建RESTful服務的強大工具，為開發者提供了便捷的方式來定義、處理HTTP請求並返迴響應。在設計API介面時，正確地接收和解析客戶端發送的數據至關重要。.NET WebAPI提供了一系列特性，如[FromRoute]、[FromQuery]和[FromBody]，用 ...
  • WPF/C#實現圖像濾鏡優化方案：打造炫目視覺體驗！
    原因：我之所以想做這個項目，是因為在之前查找關於C#/WPF相關資料時，我發現講解圖像濾鏡的資源非常稀缺。此外，我註意到許多現有的開源庫主要基於CPU進行圖像渲染。這種方式在處理大量圖像時，會導致CPU的渲染負擔過重。因此，我將在下文中介紹如何通過GPU渲染來有效實現圖像的各種濾鏡效果。 生成的效果 ...
  • Bogus 實戰：使用 Bogus 和 EFCore 生成模擬數據和種子數據【完整教程】
    引言 上一章我們介紹了在xUnit單元測試中用xUnit.DependencyInject來使用依賴註入，上一章我們的Sample.Repository倉儲層有一個批量註入的介面沒有做單元測試，今天用這個示例來演示一下如何用Bogus創建模擬數據 ，和 EFCore 的種子數據生成 Bogus 的優 ...
  • WPF隨筆收錄-實時繪製心率曲線
    一、前言 在自己的項目中，涉及到實時心率曲線的繪製，項目上的曲線繪製，一般很難找到能直接用的第三方庫，而且有些還是定製化的功能，所以還是自己繪製比較方便。很多人一聽到自己畫就害怕，感覺很難，今天就分享一個完整的實時心率數據繪製心率曲線圖的例子；之前的博客也分享給DrawingVisual繪製曲線的方 ...
  • wpf程式修改啟動入口註意事項
    如果你在自定義的 Main 方法中直接使用 App 類並啟動應用程式，但發現 App.xaml 中定義的資源沒有被正確載入，那麼問題可能在於如何正確配置 App.xaml 與你的 App 類的交互。 確保 App.xaml 文件中的 x:Class 屬性正確指向你的 App 類。這樣，當你創建 Ap ...
  • 記一次 .NET某爐膛鍋爐檢測系統 崩潰分析
    一：背景 1. 講故事 上個月有個朋友在微信上找到我，說他們的軟體在客戶那邊隔幾天就要崩潰一次，一直都沒有找到原因，讓我幫忙看下怎麼回事，確實工控類的軟體環境複雜難搞，朋友手上有一個崩潰的dump，剛好丟給我來分析一下。 二：WinDbg分析 1. 程式為什麼會崩潰 windbg 有一個厲害之處在於 ...
  • 一個.NET內置依賴註入的小型強化版
    前言 .NET生態中有許多依賴註入容器。在大多數情況下，微軟提供的內置容器在易用性和性能方面都非常優秀。外加ASP.NET Core預設使用內置容器，使用很方便。 但是筆者在使用中一直有一個頭疼的問題：服務工廠無法提供請求的服務類型相關的信息。這在一般情況下並沒有影響，但是內置容器支持註冊開放泛型服 ...
  • WPF隨筆收錄-DataGrid固定右側列
    一、前言 在項目開發過程中，DataGrid是經常使用到的一個數據展示控制項，而通常表格的最後一列是作為操作列存在，比如會有編輯、刪除等功能按鈕。但WPF的原始DataGrid中，預設只支持固定左側列，這跟大家習慣性操作列放最後不符，今天就來介紹一種簡單的方式實現固定右側列。（這裡的實現方式參考的大佬 ...
所有分類