# 第二階段第一個主軸選型比較

## 1. 文件目的

本文件用於比較第二階段第一個主軸應先選哪一條工作線，避免在第一階段剛完成後同時展開 MySQL、WebApi、ServiceHost、真實設備與 .NET 升級，導致範圍失控。

本文件只做選型分析與建議，不代表已決定實作，也不變更程式架構、資料模型、API、設定格式或啟動方式。

## 2. 候選主軸

| 選項 | 主軸 | 核心目標 |
|---|---|---|
| A | MySQL 任務持久化 | 讓任務、節點歷程與錯誤結果可保存、可查詢 |
| B | ServiceHost / WebApi 邊界 | 建立正式背景執行或遠端操作入口 |
| C | 真實設備 Adapter 驗證 | 讓 Modbus TCP / UDP 等設備接近現場測試條件 |
| D | .NET 升級評估 | 降低 `.NET 5.0` EOL 風險 |
| E | 維運與 Log 查詢 | 強化任務追蹤、錯誤判讀與工程支援效率 |

## 3. 評估標準

| 評估項 | 說明 |
|---|---|
| 對正式化價值 | 是否能讓骨架更接近可實際使用 |
| 風險控制 | 是否會大幅牽動架構、資料模型或啟動方式 |
| 對後續依賴 | 是否是其他工作線的前置基礎 |
| 可驗證性 | 是否能建立清楚的 PoC 或驗收節點 |
| 範圍可控性 | 是否能在小步驟內完成並回報結果 |

## 4. 選項比較

### A. MySQL 任務持久化

目前使用者提供的資料庫版本為 MySQL 5.6.2，後續若選擇此主軸，套件選型、SQL 語法與 schema 欄位型態都必須以 MySQL 5.6.2 相容性為前提。

優點：

- 補上第一階段最大限制：InMemoryTaskStore 重啟後資料消失。
- 對任務查詢、錯誤追蹤、WebApi、ServiceHost 都是基礎。
- 可先做 PoC，不必一次做完整報表或多案場。
- 容易建立明確驗收節點：寫入任務、重啟後查詢、錯誤資訊可追。

風險：

- 會碰到資料模型，需要先確認 schema 邊界。
- 若太早做完整 schema，可能把未來案場邏輯寫死。
- 需要確認是否引入 ORM、migration 或先用簡單 SQL。
- MySQL 5.6 系列已屬舊版支援風險版本，正式化前需另做升級或版本風險評估。

適合條件：

- 使用者確認第二階段要把任務紀錄保存下來。
- 先只做 Task / Node / Command / ErrorInfo，不做報表與多案場。

建議驗收節點：

- P2-01 MySQL TaskStore PoC：任務完成後可寫入 DB。
- P2-02 重啟查詢驗證：程式重啟後仍能查到任務紀錄。

### B. ServiceHost / WebApi 邊界

優點：

- 能把 ConsoleHost 驗證入口往正式執行模式推進。
- WebApi 可支援遠端啟動、查詢、取消任務。
- ServiceHost 可支援背景執行與長時間運作。

風險：

- 會牽動啟動方式與部署方式。
- 若沒有資料持久化，WebApi 查詢能力會受限。
- 若太早做 API，可能導致 Controller 吃進核心流程邏輯。

適合條件：

- 已確認 TaskStore / Log 查詢策略。
- 已確認第二階段要先做遠端操作或背景服務。

建議驗收節點：

- P2-03 ServiceHost 啟動 PoC。
- P2-04 WebApi contract review。

### C. 真實設備 Adapter 驗證

優點：

- 最接近現場價值，可驗證第一階段 Adapter 抽象是否真的可用。
- 可暴露通訊逾時、斷線、設備回應格式等真實問題。
- 可強化 Modbus TCP / UDP 設定規格。

風險：

- 需要設備、測試窗口、通訊參數與安全保護。
- 若現場條件不穩，容易把硬體問題誤判成架構問題。
- 可能需要新增或調整 Adapter 設定欄位，需先確認。

適合條件：

- 已有可控測試設備或模擬環境。
- 已確認不會直接控制危險動作。
- 已準備好人工驗證紀錄格式。

建議驗收節點：

- P2-05 真實設備 Adapter 安全測試。
- P2-06 連線失敗與斷線復原現場驗證。

### D. .NET 升級評估

優點：

- `.NET 5.0` 已 EOL，升級可降低正式化風險。
- 若能早期處理，後續 MySQL / WebApi / ServiceHost 可建立在較穩定版本。
- 可用測試保護升級結果。

風險：

- 可能影響套件相容性。
- 如果與其他功能同時做，失敗來源會混在一起。
- 升級本身不會直接增加業務功能。

適合條件：

- 使用者希望第二階段正式化前先降低技術債。
- 可接受先做升級 PoC，不立刻改主線。

建議驗收節點：

- P2-07 .NET 8 LTS 升級 PoC。
- P2-08 升級後全測試通過確認。

### E. 維運與 Log 查詢

優點：

- 可以提升現場問題判讀效率。
- 可先補文件與查詢格式，不一定立刻導入 DB。
- 對 ServiceHost / WebApi / MySQL 都有幫助。

風險：

- 若沒有持久化，查詢能力仍有限。
- 容易變成只整理格式，缺少實際功能成果。

適合條件：

- 使用者想先提升可觀測性，再導入資料庫或服務。
- 可以先和 MySQL PoC 搭配。

建議驗收節點：

- P2-09 任務查詢欄位定義。
- P2-10 錯誤碼與 Log 查詢格式驗證。

## 5. 建議排序

建議排序如下：

| 建議順序 | 主軸 | 理由 |
|---:|---|---|
| 1 | MySQL 任務持久化 | 是 WebApi、ServiceHost、任務查詢與維運觀測的共同基礎 |
| 2 | .NET 升級評估 | 正式化前應先降低 EOL 風險，但可用獨立 PoC 控制風險 |
| 3 | ServiceHost / WebApi 邊界 | 有持久化與版本策略後，服務入口較好設計 |
| 4 | 真實設備 Adapter 驗證 | 需要設備與現場條件，建議在資料與錯誤追蹤更穩後進行 |
| 5 | 維運與 Log 查詢 | 可與 MySQL / WebApi 並行補強，但不宜單獨作為第一主軸 |

## 6. 推薦方案

建議第二階段第一個主軸選：

> MySQL 任務持久化 PoC

推薦原因：

- 第一階段已明確接受「暫不導入資料庫」，現在進入第二階段後，這是最自然的下一個缺口。
- 不需要立即改 WebApi、ServiceHost 或真實硬體。
- 能先建立資料邊界，避免後續 API / ServiceHost 沒有穩定查詢來源。
- 可用 PoC 控制範圍，不必一次做完整正式資料庫。

建議第一個小步驟不是直接寫程式，而是先做：

1. MySQL TaskStore 資料保存範圍確認。
2. Task / Node / Command / ErrorInfo schema 初稿。
3. Repository 介面是否需要新增或沿用現有 TaskStore。
4. PoC 驗收標準。

## 7. 需先確認的問題

1. 第二階段第一個主軸是否同意先選 MySQL 任務持久化。
2. MySQL 第一版是否只保存任務歷程，不保存設備即時狀態。
3. 是否保存 RawRequest / RawResponse。
4. 是否保存 Adapter metadata。
5. 是否先做 schema 文件與 PoC 設計，再進入程式實作。
6. 是否確認第一版 PoC 以 MySQL 5.6.2 相容性為必要條件。
7. `.NET` 升級是否要在 MySQL PoC 前先做獨立評估。

## 8. 建議下一步

建議下一步做「MySQL TaskStore PoC 實作前確認清單」。

確認清單請參考：[MySQL TaskStore PoC 實作前確認清單](./mysql-taskstore-poc-checklist.md)。

此清單應先整理：

- 不改既有 public method 的前提。
- 是否新增 Infrastructure 專案或先放在既有範圍。
- MySQL schema 初稿。
- 測試資料與驗收指令。
- 第二階段文件網站進度欄位。