為什麼要做分層架構呢?

就是讓菜鳥和其他同事

容易看懂和開發你寫的程式

也就是所謂的

方便系統的程式共用維護

系統擴充

最後讓程式可以做單元測試提高系統品質

我們從下圖來看看 沒有系統分層概念程式的寫法

這在以前的ASP時代或是轉成MVC的時代

還是可以看見的寫法

假設要取得會員資料(如圖)

將輸入的參數檢查,從DB讀取的資料

邏輯處理都放在一起

邏輯處理較複雜的程式說不定好幾百行

當看到這樣的程式肯定心情也很複雜

更別說在維護有時候只是想改個參數檢查

或撈取DB的方法

但改了看到這麼多行的程式還真擔心會不會改壞什麼

然後上線後還真的不小心有Bug

老闆還以為你不專業

但其實每個人改都有風險…

所以我們應該要讓每個程式每個定義負責的更為明確

才能確保系統品質

我們來看看如果有做分層架構如圖

讓每一個層面各自負責該做的事

這樣程式也就容易懂得多了

就好像家裡書桌如果有多個抽屜每個抽屜放了不一樣類別的東西

要找也就很方便了

寫程式的時候

應該要在程式的輸入參數定義清楚,不要讓這個功能混入不應該有的輸入參數

有時候在工作的時候會看到類似這樣的程式

圖中有兩個API

一個是取得影音資料,另一個是取得影音列表資料

但是輸入參數類別都為同一個RequestParameter

這在維護上就有很大的問題
我們必須思考一個問題
如果有一天程式要交給其他人負責時
無論是菜鳥,資深人員
可以一看就懂 這才是好的程式
不要說還要翻手冊 做文件 (相信我大家都不會想看,這只是增加不該增加的工作成本)

我們從圖中可以看出來這兩個API共用一個RequestParameter Class

但以直覺來看程式 其實看不出那一個API應該會用到那一個輸入的參數

所以我們應該要分別定義不同的輸入參數如圖
取得影音資料的輸入參數為VideoDetailParameter
取得影音列表資料的輸入參數為VideoListParameter

這樣就可以很直覺的就知道那一個API應該輸入什麼參數
那天要把工作交給別人維護開發
也就不用多說明

程式與生活

為什麼會開始寫程式與生活

主要是希望能幫自己的學習與創作留下記錄(方便以後換工作能力的展現)

程式的本質其實是要解決問題

雖然有很多程式的技術名詞我也不是很懂

但重點還是在於會不會用

能不能幫使用者解決問題

就像我常去的推拿師傅 並不是什麼有名的醫大畢業

但就是能發現我的痠痛問題並解決

這才是最重要的

所以我想用生活化的角度去想想看如果自己要做什麼樣的系統

可能會遇到什麼樣的問題

來寫這個部落格