上一篇把 Project Management 的需求整理成可以實作的資料庫 Schema。資料有了存放方式,接著要決定由誰來操作:畫面與後端程式要放在同一個應用程式,還是拆成兩個可以各自開發的應用程式?
這個專案選擇前後端分離。Vue 負責瀏覽器裡的畫面與互動,ASP.NET Core 則提供 HTTP API、執行商業規則並存取資料庫。兩邊透過 API 傳遞資料,各自處理不同的工作。
前後端分離不是每個專案的標準答案,也不會讓系統自動變得更穩或更快。它只是換了一種分工方式:責任比較清楚,伴隨的管理工作也更多。
傳統 ASP.NET Core MVC 專案常把 Model、View 與 Controller 放在同一個應用程式中。瀏覽器送出 Request 後,Controller 處理請求並取得資料,再由 Razor View 產生 HTML 回傳給瀏覽器。MVC 用這三個部分劃分程式職責,而 ASP.NET Core MVC 本身既可以建立網頁,也可以提供 API。

這種作法沒有比較落後。對內容型網站、後台管理系統或規模不大的團隊來說,單一專案通常更容易開發、測試與部署。系統是否穩定則是另一件事。以工作項目系統為例,如果 MVC 站台只有一個執行個體,服務停止後,使用者自然無法開啟頁面;改成前後端分離後,如果 API 仍然只有一個執行個體,Vue 畫面或許能載入,工作項目清單與儲存功能還是不能使用。問題出在服務只有一份,而不是 MVC。要提高可用性,仍得透過多執行個體、健康檢查與負載平衡等機制處理。
改成前後端分離後,後端通常不再替主要操作畫面產生 HTML,而是透過 API 回傳 JSON 等資料。前端取得資料後,再決定畫面怎麼顯示、何時更新,以及載入中或失敗時要呈現什麼狀態。

以查詢工作項目為例,流程大致如下:
GET /api/work-items。前後端要能順利合作,雙方就得遵守 API 契約。契約包含路徑、HTTP 方法、欄位名稱、狀態碼與錯誤格式。只要其中一項改了卻沒有同步,即使兩邊的程式各自都能編譯,串接後的功能仍然會壞掉。Day 12 會再專門討論 RESTful API 與契約如何設計。
第一個原因很直接:同一套後端功能可以供不同介面使用。現在由 Vue 顯示工作項目,未來若加入手機 App,也能直接呼叫同一組 API,不必重新實作權限判斷與資料處理邏輯。前端不需要知道後端使用 C#、Dapper 或哪一套資料庫,只要遵守 API 契約即可。
第二個原因是開發與部署節奏可以分開。修改 Vue 的版面時,不一定要改動後端;API 內部若只是重構,而且輸入與輸出契約不變,前端通常也不需要跟著調整。團隊可以分工,測試範圍也比較明確。
這裡談的仍是前端 Client 與後端 Server 的分工,不是微服務。微服務處理的是另一個問題:後端要不要依業務能力拆成多個可獨立部署的服務。這次的後端仍然可以是一個模組化單體。對單人專案來說,先把一個 API 做穩,比一開始就維護多個服務、服務探索與分散式追蹤實際得多。
分工變清楚後,原本在同一個專案裡就能處理的事情,現在必須由兩邊一起約定:
是否值得負擔這些工作,要回到專案需求判斷。這個專案希望讓不同 Client 共用後端功能,也需要讓 Vue 與 API 保有各自的開發節奏,因此選擇拆開。若專案只有幾個簡單頁面,沒有其他 Client,也沒有分工或分開部署的需求,Razor Pages 或 MVC 反而可能更省事。
Day 9 把需求整理成資料庫 Schema,這一篇再把系統分成 Vue 與 ASP.NET Core API。Vue 負責畫面與操作,API 負責商業規則與資料存取,雙方按照約定好的契約交換資料。
API 開放給前端呼叫後,接著就得回答兩個問題:請求是誰送出的?這個人可以操作哪些資料?下一篇會從這裡談身分驗證、授權,以及 JWT 在其中扮演的角色。