閒談軟體設計:Model Model Model

更新於 發佈於 閱讀時間約 5 分鐘


可能是過去求學時,學的是《Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development》和《Object-Oriented Modeling and Design with UML, 2nd》書中描述的方式做物件分析與設計,從 use case 描述中抓出名詞成為 domain model,從動詞找出類別的行為和物件間的關聯,用 GRASP 原則將責任分配到合適的類別身上,但這個 domain model 離實際的 implementation model 還有段距離,畢竟還要跟使用的框架打交道。


就業後,對於 Model 這字眼總是特別小心,有趣的是,Model 其實沒什麼嚴格的定義,所以每個人對 Model 的解讀也不盡相同,有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響),有人覺得工作流程 (workflow) 是 Model 的一部份,我個人也有自己的想法,而且隨專案的規模和特性,也不是總是一樣的。

若看 Wikipedia 對 Multitier architecture 的描述,會發現常見的架構分成四層,每一層的責任似乎明確卻又有一點模糊,而我自己的見解是:

  • Presentation layer — 若是使用 server-rendering 為主要技術的框架中,這一層主要是將 application layer 的結果轉換成 HTML;若是在桌面應用程式或是 client-rendering 中,這一層主要就是 UI 相關的邏輯 (跳出對話框、切換視窗、更新視窗中的元件)。
  • Application layer — 如 Wikipedia 的描述,我亦是把這一層當作 GRASP 的 system event controller (此 controller 不等同 MVC 的 controller),並處理完成一個 use case 中非 domain (business) logic 的其他部分,例如:發送信件 (通知)、關係注入 (dependency injection)、infrastructure 或外部系統的調用、request 資料格式的檢查等。
  • Business layer — 基本上這一層只處理 domain objects 間的 relationship 以及確保最終狀態是符合 business rules,例如:在一個論文審查系統中,不能將一篇直接從 wait for review 移到 accepted 或 rejected (至少要經過審查)。
  • Data access layer — 這一層除了處理資料怎麼儲存 (persistence) 外,也包含如何從網路存取外部的資料。而在 persistence 這件事上,個人比較偏好 Repository pattern。

雖然這樣看起來,四層很明確啊!但實際在寫程式時,還是會有一些模糊的空間,有時候還是要思考這一段程式應該放在哪一層,特別是 application layer 和 business layer 之間更是如此;因此,也可以說,每個人對於 Model 到底是包含 application layer 還是 business layer 的哪些部分看法不太一致,對我來說,二者都是 Model,但若分成四層,二者不會是同一個物件。

程式的結構 (以目錄或其他方式呈現) 上,有時也不容易看出結構與分層的對應關係。有時候,強制分成四層也會讓程式架構變複雜,所以我在桌面應用程式或 Mobile App 中,我可能選擇讓 application layer 與 business layer 合併,簡化成三層,或是讓 application layer 非常的薄。

在 Web 應用中,原則上還是分成四層,但個人偏好 client-rendering,因此 presentation layer 通常在 client,不過,為了方便測試,有時候 Web server 端還是會有負責提供 presentation model 的 presentation layer。例如用 Spring 框架來撰寫,application layer 的程式有時會散在 filter (身份認證或權限控管)、interceptor (稽核) 和 request controller (直接當成 system event controller) 中,但原則上 request controller 的程式大多很短,主要邏輯還是在 business layer 裡。

或許,事情不用這麼複雜,在設計每個 class 時或是想將功能加到一個 class 時,用 single responsibility 的原則來思考,適合放在這個 class 嗎?若不合適,應該放在哪裡呢?這時候參考軟體的架構思考應該放在哪一層。在層與層之間的 dependency 該如何管理或注入時,多想想 interface segregation 原則,不要直接依賴實作,甚至可以想一下 dependency inversion 原則,降低上層程式與下層程式的依賴,盡可能讓每一層都能維持獨立,此時,要進行測試就容易多了。

總結來說,對 Model 的解讀可以各自不同,沒什麼標準答案,但不論用什麼方式解讀,只要能讓程式易讀好維護,就是好的設計。

avatar-img
53會員
104內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別,當時寫了首部曲《閒談軟體設計:API Naming Style》,接著是《閒談軟體設計:內部函式庫》,但始終沒談到 library 和 framework 的差別,主要是沒有好的例子,這次這例子還蠻不錯的。
我自己偏好用 Repository 搭配 decorator 來管理 cache,而不是在 controller 層或是到處都有快取的邏輯,如果程式都是透過 Repository 更新資料,Repository 就會是一個不錯的地方更新快取,邏輯也就不會散亂在各處了。
提到後端工程師,似乎就只是開發 API,但一個複雜的系統其實不太可能只透過 API 就能完成,例如一個簡單的功能,註冊會員,其實是由好幾個不同類型的工作互相配合,您才能收到開通信,才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
最近隨著 FP 的流行,immutability 一直被提倡,物件有狀態,會被修改好像是一種惡,但真是如此?immutability 很好,但所謂的狀態就是會隨著操作變動,差別只在於變動發生在哪裡?
針對這議題,從 devOps 的角度看,團隊應抱有持續不斷地改進的精神,努力降低上版的風險,最後,哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失,當然還要考慮到團隊要怎麼 on-call,on-call 的資源夠不夠應付上版後的突發狀況,才能做出適當的決策。
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的),問到:Singleton 對於好的架構來說是否能避免就避免呢?我簡單地回了一下我的想法 ,但 Singleton 其實很有趣,所以就寫篇文章來聊聊吧!
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別,當時寫了首部曲《閒談軟體設計:API Naming Style》,接著是《閒談軟體設計:內部函式庫》,但始終沒談到 library 和 framework 的差別,主要是沒有好的例子,這次這例子還蠻不錯的。
我自己偏好用 Repository 搭配 decorator 來管理 cache,而不是在 controller 層或是到處都有快取的邏輯,如果程式都是透過 Repository 更新資料,Repository 就會是一個不錯的地方更新快取,邏輯也就不會散亂在各處了。
提到後端工程師,似乎就只是開發 API,但一個複雜的系統其實不太可能只透過 API 就能完成,例如一個簡單的功能,註冊會員,其實是由好幾個不同類型的工作互相配合,您才能收到開通信,才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
最近隨著 FP 的流行,immutability 一直被提倡,物件有狀態,會被修改好像是一種惡,但真是如此?immutability 很好,但所謂的狀態就是會隨著操作變動,差別只在於變動發生在哪裡?
針對這議題,從 devOps 的角度看,團隊應抱有持續不斷地改進的精神,努力降低上版的風險,最後,哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失,當然還要考慮到團隊要怎麼 on-call,on-call 的資源夠不夠應付上版後的突發狀況,才能做出適當的決策。
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的),問到:Singleton 對於好的架構來說是否能避免就避免呢?我簡單地回了一下我的想法 ,但 Singleton 其實很有趣,所以就寫篇文章來聊聊吧!
你可能也想看
Google News 追蹤
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
這篇內容,將會講解什麼是資料型態,以及與資料型態相關的知識。包括資料型態的簡介、實數、布林值、 字串、陣列。
MVVMC(Model View ViewModel Coordinator),特點是Coordinator。 Model 負責儲存應用程式的資料。 View 負責顯示資料。 ViewModel 負責處理View和Model之間的狀態關係。 Coordinator 負
MVI(Model View Intent),特點是Intent。 Model 負責介面狀態 View 負責顯示資料。 Intent 負責將封裝後的操作告知Model。
MVVM(Model View ViewModel),特點是View跟ViewModel之間做資料綁定。 Model 負責儲存應用程式的資料。 View 負責顯示資料。 ViewModel 負責處理View和Model之間的狀態關係。
MVP(Model View Presenter)由MVC演變而來。MVC與MVP的差異是View跟Model之間的關係;MVC中是可以直接溝通的;MVP中是不可以直接溝通的,必須要透過 Presenter。 Model 負責資料存取。 View 負責顯示資料,並將使用者的操作傳給P
Thumbnail
樣板模式的定義極為簡單,卻是大型系統程式、WEB/APP應用框架的設計核心,完美展現設計模式的價值: 簡單、高效、強大。
Thumbnail
代理模式通過封裝原始對象來實現對該對象的控制和管理,同時不改變原始對象的行為或客戶端與該對象互動的方式,以此介入或增強對該對象的訪問和操作。
Thumbnail
語言模型與文字表示以不同的方式來分析自然語言的詞語分佈及語意關係。本文章簡要介紹了語言模型、Word2vec、FastText、GloVe和Transformer等技術,並提供了實際的應用參考點,幫助讀者深入理解自然語言處理的技術。
Thumbnail
資料的統合 在程式設計中,其他人通常關心是否注意到執行的細節。作為程式設計師,主要應該關心的是程式的表現,但往往忽略了很多細節,這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合,也就是資料是否被正規化。 不同類型的資料在系統中呈現一致 正規化可能對一些人來說聽起來很抽象,有些人
Thumbnail
替產業做設計 有人要我談程式設計,那我就稍微談一下。我從事的大都是產業的工作,所以我們也從如何替產業做設計來談起。基本上,每個產業都會有自己的作業流程,大同小異。但是基礎來做都是一樣的,都會有客戶、物料、產品、供應商、員工等資料。不同的是,由於企業型態的不同,他們每個人有不同的作業流程。這個作業流
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
這篇內容,將會講解什麼是資料型態,以及與資料型態相關的知識。包括資料型態的簡介、實數、布林值、 字串、陣列。
MVVMC(Model View ViewModel Coordinator),特點是Coordinator。 Model 負責儲存應用程式的資料。 View 負責顯示資料。 ViewModel 負責處理View和Model之間的狀態關係。 Coordinator 負
MVI(Model View Intent),特點是Intent。 Model 負責介面狀態 View 負責顯示資料。 Intent 負責將封裝後的操作告知Model。
MVVM(Model View ViewModel),特點是View跟ViewModel之間做資料綁定。 Model 負責儲存應用程式的資料。 View 負責顯示資料。 ViewModel 負責處理View和Model之間的狀態關係。
MVP(Model View Presenter)由MVC演變而來。MVC與MVP的差異是View跟Model之間的關係;MVC中是可以直接溝通的;MVP中是不可以直接溝通的,必須要透過 Presenter。 Model 負責資料存取。 View 負責顯示資料,並將使用者的操作傳給P
Thumbnail
樣板模式的定義極為簡單,卻是大型系統程式、WEB/APP應用框架的設計核心,完美展現設計模式的價值: 簡單、高效、強大。
Thumbnail
代理模式通過封裝原始對象來實現對該對象的控制和管理,同時不改變原始對象的行為或客戶端與該對象互動的方式,以此介入或增強對該對象的訪問和操作。
Thumbnail
語言模型與文字表示以不同的方式來分析自然語言的詞語分佈及語意關係。本文章簡要介紹了語言模型、Word2vec、FastText、GloVe和Transformer等技術,並提供了實際的應用參考點,幫助讀者深入理解自然語言處理的技術。
Thumbnail
資料的統合 在程式設計中,其他人通常關心是否注意到執行的細節。作為程式設計師,主要應該關心的是程式的表現,但往往忽略了很多細節,這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合,也就是資料是否被正規化。 不同類型的資料在系統中呈現一致 正規化可能對一些人來說聽起來很抽象,有些人
Thumbnail
替產業做設計 有人要我談程式設計,那我就稍微談一下。我從事的大都是產業的工作,所以我們也從如何替產業做設計來談起。基本上,每個產業都會有自己的作業流程,大同小異。但是基礎來做都是一樣的,都會有客戶、物料、產品、供應商、員工等資料。不同的是,由於企業型態的不同,他們每個人有不同的作業流程。這個作業流