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项目。