iT邦幫忙

2026 iThome 鐵人賽

DAY 11
0

Day10_我的架構不只是給網頁用,來談談什麼是前、後端分離

前言

上一篇把 Project Management 的需求整理成可以實作的資料庫 Schema。資料有了存放方式,接著要決定由誰來操作:畫面與後端程式要放在同一個應用程式,還是拆成兩個可以各自開發的應用程式?

這個專案選擇前後端分離。Vue 負責瀏覽器裡的畫面與互動,ASP.NET Core 則提供 HTTP API、執行商業規則並存取資料庫。兩邊透過 API 傳遞資料,各自處理不同的工作。

前後端分離不是每個專案的標準答案,也不會讓系統自動變得更穩或更快。它只是換了一種分工方式:責任比較清楚,伴隨的管理工作也更多。

先從熟悉的 ASP.NET Core MVC 說起

傳統 ASP.NET Core MVC 專案常把 Model、View 與 Controller 放在同一個應用程式中。瀏覽器送出 Request 後,Controller 處理請求並取得資料,再由 Razor View 產生 HTML 回傳給瀏覽器。MVC 用這三個部分劃分程式職責,而 ASP.NET Core MVC 本身既可以建立網頁,也可以提供 API。

https://ithelp.ithome.com.tw/upload/images/20260909/20126487jaqxiIkrey.png

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

前後端分離,分開的是責任與契約

改成前後端分離後,後端通常不再替主要操作畫面產生 HTML,而是透過 API 回傳 JSON 等資料。前端取得資料後,再決定畫面怎麼顯示、何時更新,以及載入中或失敗時要呈現什麼狀態。

https://ithelp.ithome.com.tw/upload/images/20260909/20126487CgwSyabX6S.png

以查詢工作項目為例,流程大致如下:

  1. 使用者在 Vue 頁面開啟工作項目清單。
  2. 前端向 ASP.NET Core API 發送 GET /api/work-items
  3. 後端驗證請求、執行查詢並回傳 JSON。
  4. Vue 根據回傳結果更新清單,或顯示錯誤訊息。

前後端要能順利合作,雙方就得遵守 API 契約。契約包含路徑、HTTP 方法、欄位名稱、狀態碼與錯誤格式。只要其中一項改了卻沒有同步,即使兩邊的程式各自都能編譯,串接後的功能仍然會壞掉。Day 12 會再專門討論 RESTful API 與契約如何設計。

為什麼這個專案選擇拆開?

第一個原因很直接:同一套後端功能可以供不同介面使用。現在由 Vue 顯示工作項目,未來若加入手機 App,也能直接呼叫同一組 API,不必重新實作權限判斷與資料處理邏輯。前端不需要知道後端使用 C#、Dapper 或哪一套資料庫,只要遵守 API 契約即可。

第二個原因是開發與部署節奏可以分開。修改 Vue 的版面時,不一定要改動後端;API 內部若只是重構,而且輸入與輸出契約不變,前端通常也不需要跟著調整。團隊可以分工,測試範圍也比較明確。

這裡談的仍是前端 Client 與後端 Server 的分工,不是微服務。微服務處理的是另一個問題:後端要不要依業務能力拆成多個可獨立部署的服務。這次的後端仍然可以是一個模組化單體。對單人專案來說,先把一個 API 做穩,比一開始就維護多個服務、服務探索與分散式追蹤實際得多。

拆開後要付出的成本

分工變清楚後,原本在同一個專案裡就能處理的事情,現在必須由兩邊一起約定:

  • 前後端需要共同維護 API 文件與版本相容性。
  • 不同網域、通訊協定或連接埠之間的瀏覽器請求,必須正確設定 CORS。CORS 是瀏覽器的跨來源存取規則,不是 API 的身分驗證機制。
  • 登入狀態、Token 保存、逾時、錯誤格式與重試策略都要明確設計。
  • 前端與後端各有建置流程、測試與部署設定,維運項目自然會增加。
  • 後端故障時,靜態前端也許仍能載入,但需要 API 的功能還是無法使用,因此前端必須準備清楚的失敗畫面。

是否值得負擔這些工作,要回到專案需求判斷。這個專案希望讓不同 Client 共用後端功能,也需要讓 Vue 與 API 保有各自的開發節奏,因此選擇拆開。若專案只有幾個簡單頁面,沒有其他 Client,也沒有分工或分開部署的需求,Razor Pages 或 MVC 反而可能更省事。

小結

Day 9 把需求整理成資料庫 Schema,這一篇再把系統分成 Vue 與 ASP.NET Core API。Vue 負責畫面與操作,API 負責商業規則與資料存取,雙方按照約定好的契約交換資料。

API 開放給前端呼叫後,接著就得回答兩個問題:請求是誰送出的?這個人可以操作哪些資料?下一篇會從這裡談身分驗證、授權,以及 JWT 在其中扮演的角色。

參考資料


上一篇
Day9_好的資料庫設計,讓你的程式更有彈性
下一篇
Day11_API不是人人都可以呼叫的,來談談什麼是JWT
系列文
Codex的規格驅動開發 :30 天打造 .NET 內部專案管理系統14
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言