為何需要 Repository Design Pattern

在最近參與的專案當中，我們開始導入了 Repository Design Pattern，一句話總結它的用途就是「負責處理資料的新增、讀取、更新、刪除 (CRUD) 的角色」，建立這樣一個角色來負責處理資料能帶來什麼好處呢？

期待已久的 iPlayground 2019 的影片終於弄好上線啦，感謝工作人員的辛勞！趕緊去瞧瞧!

這是我講的「漫談 iOS 架構：MVC / MVVM / VIPER 與 Redux」，搭配之前的文章觀看會更清楚。

很榮幸我能在今年的 iPlayground 分享了過去幾年以來，我對於 iOS 架構的一些看法與心得，投影片由此下載，本文則是比較詳細的文字稿。

這幾年大家逐漸重視 iOS 的架構設計，從最基本的 MVC 到開始普及的 MVP / MVVM，到分工細膩的 VIPER，每個 pattern 都有擁護者；近期也有為了解決畫面轉換的 Router / Coordinator 以及為了解決資料一致性的 Redux。

我們 app 早期的架構是 MVC，後來改成 MVVM，後來為了因應複雜的流程所以引進 Coordinator，也引進 Redux 處理資料一致性的問題。

接下來會聊聊這幾種 pattern 及其演化過程。

有一定的程式設計經驗之後，會愈來愈感受到程式架構的重要性，在 iOS app 開發的世界裡，最常見的莫過於 MVC 架構，因為它夠簡單而且是蘋果推薦的架構。但當你的程式越來越龐大，流程越來越複雜的時候，就會發現 MVC 架構已經無法滿足需求了。這幾年最為人所知的就是 MVP / MVVM / VIPER / Coordinator 這幾個模式。

我認為這些模式的著眼點都在於「UI」：它們假設你有一套辦法去存取或修改資料，然後它們提出的方案是關於如何處理「界面顯示 / 使用者互動 / 資料存取」之間的關係。