※ 引述《DongFeng ()》之銘言： : : 目前手上的 Project 使用 Laravel Framework 開發, 程式碼架構依目錄區分為 Controller(Presentation)->Service(Business)->Repository(Data)->Entity : : 基本上各層的存取範圍以箭頭方向為準且不可逆, 但因為協同開發的關係偶爾還是會出現 Controller直接存取Repository的情況 : 有興趣可以參考 Uncle Bob 的 Clean Architecture，YouTube 上有演講錄影， 也有出書，網路上也可以找到實際的程式碼。但因為是概念性的東西，每個人的 理解和實作都有些不同。 我覺得他有一個好處，是可以跳脫 Framework 的思維，單純回歸到最原始的 OOD 的概念。這也是為什麼每個語言 / Framework 都可以實作 Clean Artitecture， 但每個人做得出來的東西又都長得不太一樣的原因。 : : : 因為沒有新的 feature/issue 的關係, 所以本週有空檔可以回頭整理之前寫的程式碼 : : 越整理我就越沮喪 : : 我發現自己沒有分辨哪些邏輯該歸類到哪一層的能力, 舉例來說: : 說真的，我自己是覺得很多時候都是 trade-off，但如果真的很在意，其實這個 架構提供了一個滿不錯的指引，但即使有這份指引，還是要考量很多東西。沒有 最好的架構，只有最適合當下情境的架構。 這篇文章我會試著以我的思路，提出一些問題，再提供一些假想的情境，然後說 明如果是我，我會怎麼安排。 Clean Architecture 把系統畫分成以下幾個組件，而且各自的職責非常清楚： 1. 與核心業務邏輯相關的，抽象的組件，這些組件不應該知道任何的實作細 節，例如資料庫，Controller 等等。 - Entity - UseCase 物件 2. 讓實作細節與核心業務邏輯溝通用的介面，通常又分兩類： - 從某處拉資料，例如 Repository 介面 - 把資料送到某處，例如 Presenter 轉換成讓 Controller 往外吐的 JSON 3. 實作上述介面的類別，也就是實作細節 : -- : 有一個 MemberService 的 Class, 負責跟會員有關的操作 : : 裡頭有一個方法 paginate 會回傳指定頁數與數量的會員資料, 除了吃指定頁數與數量的參數以外這個方法也吃另一個叫 $filter 的參數 : 視情況，在 Clean Architecture，單單是「取得分頁及過濾過後的使用者資料」這件事， 就很有可能是獨立的一個 UseCase 物件了。下面我就單以這個功能來說： 他的「行為」和「順序」是什麼？ 1. 撈資料 2. 過濾資料 3. 分頁資料 接下來，我會先問幾個問題，再來確定職責所在： 1. 過濾條件也多複雜？ 2. 資料量有多大？ 3. 分頁這件事，會不會有其他人要用到？ 撈資料不用講，一定是 Repository 的職責，因為 UseCase 不管實作細節，他 不會知道資料存在哪，是 SQL 或 NoSQL，或只是一個簡單的文字檔，他一定要 靠 Repository 才能取得資料。 過濾條件有多複雜，會影響到要把這件事排在哪做： 1. 相對應到一個簡單的 SQL 的 WHERE 指令？那我很可能選擇直接在 Repository 做。 2. 需要額外的計算，而且還要配合第三方的資料？那我會認為他應該在 UseCase 做。 資料量有多大，會影響到分頁應該是誰的職責： 1. 不大，頂多幾千到幾萬，而且其他地方也會用到分頁？ 那分頁應該是獨立的 UseCase，而取得分頁過後的使用者列表，其第三個步驟， 應該只是把一二步驟取得的使用者列表丟給分頁的 UseCase，分頁這件事的職 責甚至不屬於「取得分頁過後的使用者列表」這個 UseCase 物件。 2. 資料量很大，不可能全部撈完再分頁？而且也沒有其他地方要分頁？ 那這樣的情況，我會認為分頁是 Repository 的職責，讓資料庫去做這件事。 不然可能撈資料就撈到天慌地老，客戶打電話來幹譙。 : $filter 是陣列型態, 我會在方法的最開始檢查這次的 $filter 傳了哪些篩選條件進來 & 這些篩選條件有沒有符合預期的型態 : 在這裡我會想: $filter是陣列豈不是說其他要使用這個方法的人還需要知道可用的 key 有哪些? 那是不是把 $filter 拿掉改成 addNameFilter(value)->addGenderFilter(value)->paginate(page, perPage) 這樣比較好? 我倒覺得這不是問題，人家要用你的 API 本來就要懂要怎麼用，文件寫好一點就好了。 各有各的優缺點，key-value 是彈性大，method 是定義明確，看你的需要。 : : 我可以很快的完整交待的 feature/issue, 只要我能夠忍受程式碼職責切分不清 : : 但事實是我也想不出更好的寫法, 深深感受到自己的無力也對於沒有任何產能感到壓力 : 我覺得癥結點在於，你問了很多問題，但卻沒有問：「現在是什麼情境？」 配合不同的情境，同一件工作，本來就有可能需要分配給不同組件，所以在問一個職責 該分配給誰的時候，我覺得更應該問的是，「我現在面對的是什麼狀況」，不然很難有 一個好的切題的回答啊。 -- ~ 白馬帶著她一步步地回到中原。白馬已經老了，只能慢慢地走， 'v' Brian Hsu 但終是能回到中原的。江南有楊柳、桃花，有燕子、金魚…… // \\ ( 墳 墓 ) /( )\ 但這個美麗的姑娘就像古高昌國人那樣固執。 【白馬嘯西風】 ^`~'^ http://brianhsu.moe 『那都是很好很好的，可我偏不喜歡。』 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.251.151.199 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1530873938.A.A06.html