本文
先前完成了 API，接下來聊聊目前這樣做法可能會碰到的問題。
1、程式碼四散。
現在做法是從 Controller 決定執行動作後，到 Repository 撈取 DB 資料後回傳 json；那麼今天假如有要處理的關鍵商業邏輯，是該寫在 Controller 或是 Repository 呢？
又如果今天多人合作的情況下，甲覺得應該放在 Repository、而乙覺得應該放在 Controller ，這樣就會造成程式碼四散，對後續要維護的人造成很大的困擾。
2、容易有重工。
現行做法如果多人合作的時候，可以用 Repository 名稱來定義是從哪個 DB 撈取資料； Controller 也可以明確定義出接口，那承上所述的商業邏輯呢？又或是因為大家要處理的 Model 不同因此再合作的時候建了一堆不同的 Model 出來，卻其實是撈同一個 Table 的資料，應該想辦法避免做重複的事情。
3、耦合過高。
現行做法很容易再單一的 class 做了太多事，還記得前幾篇提到的 SOLID 原則嗎？若所有事情都包在同一個 class中完成，藕合度就會過高這種情況應該要想辦法解決。
那有甚麼好方法呢？
像傳統的 MVC 就是把程式分成 Model-View-Controller。
- 1、Model：處理商業邏輯、資料傳輸的 Model、與資料庫進行溝通。
- 2、Controller：負責當接口、控制程式的流程。
- 3、View：負責呈現，ex:畫面啦、程式應該回傳的結果。
透過將程式分開讓藕合性降低、也讓後續維護者好維護。
其他如:DDD、三層式架構等，都有自己得優缺點，下篇我們會介紹三層式架構，再將 API 實作。