三層式架構 | Sian

前言

接下來開始講解三層式架構，這是工作以來第一個學會的架構，也使用了一段時間，就以這段時間自己的體悟來敘述。

本文

為甚麼要分層呢？

前一篇我們提到，如果程式全部一條龍寫到底，後續會產生很多問題，難以維護、難以閱讀、更甚至是萬一人家要接手你的程式碼，這時候改Ａ壞Ｂ，耦合度過高的情況下，~~你只能祈禱接手的人不知道你住哪~~。

這種情況下只有自己寫可能還好，那如果需要跟人合作呢？
大家可能容易出現重複的 Code，也難以說明誰該負責寫哪部分。

這時候有一個好的架構，就很重要了。

優缺點

優點
1、較好形成一個規範，可做為標準化流程。
2、提高重用性，透過分層將相同類型的程式碼放在一塊。
3、團體合作的時候，能夠分層進行；開發人員只需專注於自己開發的那一層即可。
4、具有好的開放性、可擴充性優點。
5、降低程式碼之間的依賴，每層溝通是透過介面。
6、提高系統安全性，因為使用者需要透過 Service 層才有機會與下一層 Repository 撈取資料。

缺點
1、增加了開發成本，傳統一個人負責寫到底；分層下需要多人進行合作。
2、調整程式可能會出現連動性；有的時候修改一個地方，會導致其他層也需要跟著調整。
3、相較於一條龍開發系統性能下降，原本程式可以直接透過DB撈取資料，現在需要透過中間層的轉介才能夠拿到。

簡介

三層式架構顧名思義，主要分為了三層：

1、Controller：控制層，作為接口。
2、Service：商業邏輯層，只要有關商業邏輯部分的處理全部放在這一層。
3、Repository：倉儲層，作為資料存儲的一層。
4、Common：共用層，作為存放各層會用到的相同東西。

他們之間的關係如下圖:

Service

從最重要的 Service 層開始講解起。

在我們程式中『最重要』的就屬於商業邏輯了，這一層是會特別關注的一層；這邊大家可能會問，那商業邏輯是指哪些呢？

我自己認為最簡單分辨的方式，舉凡任何需要對資料特別處理的地方都會是放在這一層，如常見的：登入驗證、加減法運算、確認是否驗證成功等。

Controller

在我們 WebAPI 中，Controller 就屬於接口，負責處理 Router，如常見的：Get、Post、Patch 等，都會是在這層負責接應相對應的路由。

Repository

資料倉儲層，這層主要處理『有關資料串接』的部分，如：資料庫連接、下 SQL 取 Table 資料等，都會是在 Repository 處理。

這邊有個特別的地方，如果我們程式需要透過別人的API取的資料回來做處理呢？

那與對方 API 串接的地方就會是 Repository，所以 Repository 是處理『有關資料串接』的地方，而這資料當然並不只限於從 DB 撈取的資料。

Common

共用層相對單純，存放各層間會用到的共同東西，最常見的例如：Enum，就會放在這一層。

各層相互傳遞的參數

各層間會有自己的 Model，就是透過這些 Model 來溝通，如下圖：

Controller：接收的是 Parameter，輸出的是 ViewModel。
Service：接收的是 InfoModel，輸出的是 Dto。
Repository：接收的是 Condition，輸出的是 DataModel。

使用三層式架構常見的問題

1、三層式架構與傳統 MVC 有甚麼不同呢？

傳統 MVC 分成，View(展示層)-Model(資料層)-Controller(控制層)，這邊與三層式架構最大的區別在於傳統MVC並沒有特別把『商業邏輯』抽出來；常會看到傳統 MVC 可能會把商業邏輯附加在 Controller，所以 MVC 與三層式架構是不同的。

2、各層間溝通一定要透過 Model 嗎？

這個答案就我個人使用的理解是，『不一定要透過 Model』，如果只是要回傳簡單的 bool 、或是一兩個參數，直接傳就可以了；那做成 Model 的用意呢？當然也是為了提高重用性，例如我們前幾篇所用的 ResultModel。

    public class ResultModel
    {
        /// <summary>
        /// 結果
        /// </summary>
        public bool Result { get; set; }
        /// <summary>
        /// 提示訊息
        /// </summary>
        public string Message { get; set; }
    }

雖然只有兩個變數，但還是把它包成了 Model ，因為有很多個地方會需要用到，當然就可以包起來給大家共同使用。

3、Service 層可以呼叫其他Service層的程式嗎？

可以，三層式架構的優點就是要提供重用性，當然如果相同的事情在其他地方已經有做過了，直接拿來使用，就不用做重複的事情。

4、Model 的名稱分了這麼多？不能直接一個通到底嗎？

這問題也是我一開始不太能夠理解的部分，如果是一個人寫程式的時候都會為了方便，就一個 Model 通到底吧；這時候肯定會有人問就算多人合作也可以啊？

真的可以嗎？
各層間的職責都不同，從 Reoisitory 取出來的資料丟給 Service 做處理，有可能不需要全部完整的資料回傳給 Controller ，為了避免這種情況當然是分開會比較妥當，自己使用自己的 Model；多人合作的時候只需要定義說好相互要傳遞的參數就可以分層開發了，也不會因為一個 Model 而影響對方。

後記

剛開始學會三層式架構，就只知道這樣用就對了，其實沒有多大的體悟；但當開始熟練工作後被分配到維護舊系統，就會知道三層的好，老舊系統一條龍寫到底，對後續接手的人真的是極度不友善，為了找一個問題，商業邏輯四散各地，這時候真的是頭很痛，一不小心就會開始看Git紀錄找是誰寫的了(?

因此提供三層式架構給大家參考，當然其他還有很多不同的架構，有興趣的話也可以研究看看。

前言

本文