前言

當我實作畫面流程時，我會為一組「流程」建立一個 Coordinator。如果這組流程很複雜，它可以拆分成多個「子流程」，那每一個子流程也會有對應的 Sub-Coordinator。主流程的 Coordinator 可以管理子流程的 Sub-Coordinator。

Coordinator 用來管理流程的畫面，它負責建立畫面、傳遞資料給畫面、回應畫面的請求、移除畫面等等。如果用 tree 來理解畫面流程的話，Coordinator 就是 root，各個畫面就是 leaf。換個角度看，Coordinator 像一個容器 — 它自己不產出畫面內容，而是決定裡面放哪些畫面、什麼時候切換。

為何需要 Repository Design Pattern

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

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

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

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

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