MVC設計模式iOS中的項目結構

Question

首先，我很了解MVC，並且已經在項目中使用它，但是當涉及組織類和角色時，我有點不確定是否有正確的實現。 讓我們來看一個場景：

將顯示所有員工和部門的示例。 數據將從Web Services（Json）獲取，並將作為脫機存儲（Core Data）。

所以MVC模式將是：

1. View將是我的故事板與Employee和Department UIViewController。
2. Controller將是EmployeeViewController.swift和DepartmentViewController.swift

3. Model將是Employee.swift和Department.swift

    class Employee: NSObject { var name: String? } class Department: NSObject { var departmentName: String? } 

   4. ServiceManager將調用Web服務。

   5. ParseData將解析Web服務響應並將其轉換為Employee和Department對象

   6. CoreDataManager是用於管理脫機數據庫上的CRUD操作的單例類。

以下是我對上述場景的一系列問題：

1. 我的理解是否正確？ 我正在嘗試構建的結構是否遵循適當的MVC？
2. 控制器如何與這些組件交互（Service Manager，ParseData，CoreDataManager）。 是否應該有另一個類來促進控制器和數據管理之間的通信（如果控制器執行此操作，那么它將是一個緊密耦合的結構和大量的）。
3. Model應該具有除了屬性和初始化方法之外的任何代碼，因為我看到的大多數模型只有屬性聲明嗎？
4. 是否應該有單獨的UIView類而不是故事板來創建適當的MVC結構？

Answer 1

我的理解是否正確？ 我正在嘗試構建的結構是否遵循適當的MVC？

首先，我會說“適當的”MVC將取決於你問的是誰。 它的起源通常歸功於Trygve Reenskaug，當他在70年代將其引入Smalltalk時。 然而，他的MVC類型與今天最常用的臃腫版本有很大不同。 關於MVC的現代思維方式是

• Model =主要是一個主要封裝數據的啞類
• 查看=我們在屏幕上顯示的內容
• Controller =幾乎完成所有操作的大塊代碼，有時由一個或兩個經理類卸載

然而，Reenskaug將擁有一個模型，一個視圖和一個按鈕控制器。 對於標簽。 對於一個領域。 我不是說這是我們應該努力的目標，但是應該有更好的方法來構建項目，而不是使用M assive V iew C ontroller模式（因為它在iOS社區中被戲稱地引用）。

幸運的是，有。

鮑勃叔叔正在宣傳清潔建築 。 有幾個這樣的實現，各種各樣的人已經為iOS做了自己的實現，比如VIPER和Clean Swift 。

控制器如何與這些組件交互（Service Manager，ParseData，CoreDataManager）。 是否應該有另一個類來促進控制器和數據管理之間的通信（如果控制器執行此操作，那么它將是一個緊密耦合的結構和大量的）。

遵循Clean Architecture的原則，您應該將這些功能封裝到層中，這樣您不僅可以將代碼拆分為多個組件，還可以在需要時將其替換為其他組件。 （但是，是的，至少要避免將所有這些都放在你的控制器中！）

Model應該具有除了屬性和初始化方法之外的任何代碼，因為我看到的大多數模型只有屬性聲明嗎？

同樣，這里沒有一個答案。 “真正的”OOP的一些支持者會說每個對象應該是自助服務的（即模型對象應該知道如何自我保持），而其他人則將這些操作的知識提取到“管理者”中。 將代碼保存到對象中的代碼可能意味着將持久性功能亂丟到許多對象中，或者需要依賴子類或其他解決方案來避免這種耦合。

是否應該有單獨的UIView類而不是故事板來創建適當的MVC結構？

故事板與否無法確定您是否正在使用“適當的”MVC。 此外，您選擇哪種類 （UIView或UIViewController）來表示View也不重要。 你的ViewController可以被愚蠢到它不包含邏輯的程度（將它所擁有的邏輯轉發給另一個類，即VIPER中的Presenter）。

我建議您閱讀有關Clean Architecture的內容，也可以觀看Bob叔叔解釋它的視頻 ，閱讀其他人關於實現它的報告 ，然后考慮MVC是否適合您的iOS項目。