MVC设计模式iOS中的项目结构

Question

首先，我对MVC了如指掌，并且已经在项目中使用它，但是当涉及组织类和角色时，我有点不确定是否有正确的实现。让我们来看一个场景：

将显示所有员工和部门的示例。数据将从Web Services（Json）获取，并将作为脱机存储（Core Data）。

所以MVC模式将是：

1. View将是我的故事板，包含Employee和Department UIViewController。
2. Controller将是EmployeeViewController.swift和DepartmentViewController.swift

3. 模型将是Employee.swift和Department.swift

   app-vue

   1. ServiceManager，它将调用Web服务。

   2. ParseData将解析Web服务响应并将其转换为Employee和Department对象

   3. 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社区中被戏称为引用）。

幸运的是，有。

Uncle Bob正在讲道Clean Architecture。有几个这样的实现，各种各样的人已经为iOS制作了自己的实现，如VIPER和Clean Swift。

  

控制器如何与这些组件交互（服务   经理，ParseData，CoreDataManager）。应该有另一个班级   这将促进控制器和数据之间的通信   管理（如果控制器执行此操作，那么它将紧密耦合   结构和大规模）。

遵循Clean Architecture的原则，您应该将这些功能封装到层中，这样您不仅可以将代码拆分为多个组件，还可以在需要时将其替换为其他组件。 （但是，是的，至少要避免将所有这些都放在你的控制器中！）

  

Model应该具有除属性和初始化之外的任何代码   方法，因为我见过的大多数模型只有属性   声明？

同样，这里没有一个答案。 “真正的”OOP的一些支持者会说每个对象应该是自助服务的（即模型对象应该知道如何自我保持），而其他人则将这些操作的知识提取到“管理者”中。将代码保存到对象中的代码可能意味着将持久性功能乱丢到许多对象中，或者需要依赖子类或其他解决方案来避免这种耦合。

  

是否应该有单独的UIView类而不是故事板   创建一个合适的MVC结构？

故事板与否无法确定您是否正在使用“正确”的MVC。此外，您选择的类（ kind ）（UIView或UIViewController）来表示View也不重要。你的ViewController可以被愚蠢到它不包含逻辑的程度（将它所拥有的逻辑转发给另一个类，即VIPER中的Presenter）。

我建议您阅读有关Clean Architecture的信息，也可以观看video of Uncle Bob explaining it，阅读其他人的reports on implementing it，然后考虑MVC是否适合您的iOS项目。