SYSM001Controller 系統參數資料查詢編輯

發表於 2024-09-12 分類於 WDS 閱讀次數：

這段程式碼是 ASP.NET Core Web API 控制器的實現，用於處理系統參數的查詢和編輯作業。它包括三個主要的 API 操作，每個操作都對應到不同的功能。以下是這段程式碼的詳細解析：

控制器類別：`SYSM001Controller`

這個控制器繼承自 BaseController，並使用 ApiController 特性來支持 Web API 功能。它被標註為路由 api/[controller]，這意味著它的路由會根據控制器的名稱（去掉“Controller”）來生成。例如，這個控制器的路由是 api/SYSM001。

依賴注入

服務：
- _service：SYSM001Service 的實例，用於處理與系統參數相關的業務邏輯。
- _commonService：CommonService 的實例，用於處理通用的業務邏輯，例如查詢系統別資料。
建構子：
控制器通過建構子注入了 SYSM001Service、CommonService 和 ILogger<SYSM001Controller>。這樣可以在控制器中使用這些服務來執行相應的業務邏輯並記錄日誌。

API 操作

Get 方法：系統參數資料明細查詢作業
- 路由：/api/SYSM001/Query
- HTTP 方法：POST
- 參數：SYSM001Q_InputVo，用於查詢系統參數的輸入參數。
- 返回：ApiResult<List<SYSM001Q_OutputVo>>，包括查詢結果和狀態碼。
- 邏輯：
  - 調用 _service.QueryDetailResult(inputVo) 查詢詳細資料。
  - 根據返回的狀態設置 ApiResult 的結果代碼和消息。
QuerySyst 方法：小視窗 => 系統別資料查詢作業
- 路由：/api/SYSM001/QuerySyst
- HTTP 方法：POST
- 參數：SubSyst_InputVo，用於查詢系統別資料的輸入參數。
- 返回：ApiResult<List<SubSyst_OutputVo>>，包括查詢結果和狀態碼。
- 邏輯：
  - 調用 _commonService.QuerySubSystemResult(inputVo) 查詢系統別資料。
  - 根據返回的狀態設置 ApiResult 的結果代碼和消息。
Post 方法：系統參數資料編輯作業
- 路由：/api/SYSM001/Edit
- HTTP 方法：PUT
- 參數：List<SYSM001E_TotVo>，用於編輯系統參數的輸入參數。
- 返回：ApiResult<int>，包括操作結果和狀態碼。
- 邏輯：
  - 調用 _service.EditResult(inputVo) 進行編輯操作。
  - 根據返回的狀態設置 ApiResult 的結果代碼和消息。

`ApiResult` 和 `ServiceResult`

**ApiResult**：
- 一個泛型類別，用於封裝 API 的返回結果和狀態代碼，通常包括 RESULT_CODE 和 RESULT_MESSAGE。
**ServiceResult**：
- 一個泛型類別，用於封裝服務層的返回結果和狀態，通常包括 status 和 message。

這段程式碼的主要目的是提供系統參數的查詢和編輯功能，通過不同的 API 端點來處理不同的業務需求。

路由是什麼意思, 可以用一般生活中的點餐系統來解釋嗎?

當我們談論 Web API 中的路由時，可以將其比作餐廳點餐系統中的點餐流程。這樣的比喻可以幫助理解路由的概念。

路由的概念

在 Web API 中，路由（routing）是指將進來的 HTTP 請求（比如用戶的點餐要求）正確地指向處理該請求的程式碼（比如廚房的特定工作區）的一種機制。簡單來說，路由決定了當用戶發出一個請求時，應該由哪個控制器（處理請求的程序）來處理。

用餐廳點餐系統來解釋

假設你在一家餐廳點餐，以下是如何將這個點餐系統與 Web API 路由進行類比：

餐廳菜單（API 路由表）：
- 餐廳菜單列出所有的菜品及其編號。每個菜品對應著一個具體的編號，這就像是 API 路由表中列出的每個端點（endpoint）。
點餐單（請求）：
- 當你點菜時，你會告訴服務員你想要什麼（比如“我要一份披薩”）。這就像是發出一個 HTTP 請求，請求中包含了你想要的操作（比如查詢某個資源）。
服務員（路由器）：
- 服務員根據你的點餐單把你的要求記錄下來，然後將它們送到廚房的特定工作區（比如披薩區）。在 Web API 中，路由器就像這位服務員，它根據請求的 URL 和 HTTP 方法（GET、POST、PUT、DELETE 等）將請求導向到正確的控制器和方法。
廚房（控制器）：
- 廚房內部有不同的工作區負責不同的菜品。比如，披薩區負責做披薩，漢堡區負責做漢堡。在 API 中，控制器就像這些工作區，它們負責處理特定的業務邏輯和返回結果。
服務員送餐（返回結果）：
- 廚房做好了菜品後，服務員將它送到你的桌子上。這就像 API 處理完請求後，將結果返回給客戶端。

例子

假設餐廳的菜單上有以下項目：

api/SYSM001/Query：用來查詢系統參數資料。
api/SYSM001/QuerySyst：用來查詢系統別資料。
api/SYSM001/Edit：用來編輯系統參數資料。

當你發出一個點餐要求（比如api/SYSM001/Query），服務員（路由器）會根據你的要求把它送到對應的工作區（控制器方法）來處理。處理完成後，結果會被送回到你的桌子上（返回給客戶端）。

那依賴注入呢? 可以用點餐系統比喻嗎?

當我們談到依賴注入（Dependency Injection，DI）時，將其比作點餐系統中的一個特定場景可以幫助更好地理解這個概念。依賴注入是一種設計模式，用來解耦組件之間的關係，讓系統更易於維護和擴展。

依賴注入的概念

在程式設計中，依賴注入是將一個物件所需的依賴項（即它需要的其他物件）從外部提供給它，而不是由物件自己去創建或查找這些依賴項。這樣做的好處是可以提高系統的靈活性和可測試性。

用點餐系統來解釋

假設你在一家餐廳點餐，以下是如何用點餐系統來解釋依賴注入的概念：

餐廳廚房的設置（依賴項）：
- 廚房有不同的工作區（比如做披薩的區域、做漢堡的區域），每個區域都需要不同的設備（比如烤箱、燒烤爐等）。這些設備就像是工作區的依賴項。
點餐系統中的服務員（依賴注入）：
- 在這個點餐系統中，服務員是負責將點餐單送到適當的工作區（比如將披薩的訂單送到做披薩的區域）。這就像是依賴注入的過程：服務員（依賴注入機制）將所需的依賴項（點餐單）提供給工作區（物件）。
點餐單（依賴配置）：
- 在點餐時，服務員會根據你的要求將點餐單送到正確的工作區。這個點餐單包含了你需要的食材和要求，這就像是依賴配置，告訴工作區（物件）它需要什麼。
工作區的操作（物件的業務邏輯）：
- 每個工作區根據收到的點餐單進行操作（比如製作披薩）。它不需要知道所有的食材來源，只需要知道如何使用它們。這就像是物件依賴注入後的業務邏輯，它不需要知道依賴項的具體實現，只需要使用它們來完成自己的工作。

例子

假設你在點餐時指定了以下要求：

需要一份披薩（需要烤箱、麵團、配料等）。
需要一份漢堡（需要燒烤爐、肉餅、麵包等）。

服務員（依賴注入機制）將這些需求（點餐單）送到相應的工作區（比如披薩區和漢堡區）。工作區（物件）在接收到需求後，使用它們（依賴項）來完成訂單（業務邏輯）。

總結

依賴注入就像是餐廳的服務員根據點餐單把所需的食材和設備送到不同的工作區。這樣，工作區（物件）不需要自己去尋找或創建食材（依賴項），而是由服務員（依賴注入機制）負責提供所需的依賴。這樣的設計讓工作區（物件）可以專注於完成自己的工作（業務邏輯），而不需要關心依賴項的管理和配置。

也就是說服務員不只要送菜單還要依照菜單上的需求送相關的材料設備去工作區是嗎?

是的，正確！在依賴注入的概念中，服務員的角色不僅是將點餐單送到工作區，還需要根據點餐單上的需求，提供所需的材料和設備。這樣的比喻可以更清楚地說明依賴注入的工作方式：

依賴注入的比喻

點餐單（需求）：
- 顧客提供點餐單，上面列出他們的需求，比如需要一份披薩和一份漢堡。
服務員（依賴注入機制）：
- 服務員的工作是根據點餐單的內容，將所需的材料和設備送到正確的工作區。這樣，披薩的材料會送到披薩區，漢堡的材料會送到漢堡區。
工作區（物件）：
- 每個工作區（披薩區和漢堡區）按照服務員提供的材料和設備，進行製作。不需要自己去尋找或準備這些材料和設備，而是專注於根據點餐單完成訂單（即處理業務邏輯）。

實際的工作流程

點餐：
- 顧客點了一份披薩和一份漢堡。
服務員接單：
- 服務員根據點餐單準備好所有所需的材料和設備。
提供材料和設備：
- 服務員將披薩的材料和烤箱送到披薩區，將漢堡的材料和燒烤爐送到漢堡區。
工作區製作：
- 披薩區利用提供的材料和烤箱製作披薩，漢堡區利用提供的材料和燒烤爐製作漢堡。
完成訂單：
- 每個工作區完成其指定的工作，不需要關心材料的來源或準備，僅需專注於製作食物。

總結

在這個比喻中，依賴注入就像是服務員按照點餐單準備並送達所需的材料和設備，確保每個工作區可以專注於其核心職責（製作食物）。這樣的方式使得工作區（物件）與其所需的材料和設備（依賴項）之間的關係變得更清晰，並且提高了系統的靈活性和維護性。

控制器類別：SYSM001Controller