在 MVC 模式中，我看到了构成数据模型的类与驱动系统的这些类的实例之间的区别。我的团队恭敬地不同意我的观点，我想澄清一下。
我有一个Employee类是模型中唯一的类。控制器具有该类的一个实例，该实例驱动视图。
我会将Employee控制器拥有的类的一个实例称为“模型”，而将Employee不驱动系统的类的任何其他实例称为“不是模型”。
我之所以做出这种区分是因为我的团队认为视图不应该创建模型。我同意，但我认为视图应该能够创建Employee类的实例以传递给控制器。
例如，如果我setCoworker(employee : Employee)在控制器中有一个方法，我认为视图创建一个新实例Employee并将其传递给控制器是完全可以的。
MVC 模式的最佳实践规定了什么？我不应该从视图中创建实例吗？
这在一定程度上取决于您遵循的 MVC 模式（有很多风格）。不过，一般来说，View 的唯一职责应该是将人类输入转换为对 Controller 的调用，并将 Model 保存的任何数据状态转换为输出给人类。
所以我必须同意你的团队。您可能OnClick在视图中有一个按钮处理程序等，然后调用controller.BuildANewModel()，但您不会让视图自己实例化新模型。
就是说，上次我检查时，四人组已经挂了他们的棒球棒和轮胎铁杆，并没有对那些不遵守规则的人进行打击，所以不管怎样都行为你。. . :)
视图不应该将任何东西传递给控制器。控制器不应该向视图传递任何东西。模型层不应该向控制器返回任何东西。以下是在 MVC 中应该如何实现信息流：
Source: wikipedia
此外，模型是一个层。不是类或对象。包含多个结构的层，每个结构都有不同的职责。您所说Employee的不是模型（甚至不是“模型”）。相反，它只是众多领域对象之一。
您的视图和控制器都不应直接访问域对象。相反，它们应该通过服务层与模型层交互，服务层包含模型层内的“应用程序逻辑”（域和存储结构之间的交互）。
这将是我在这个主题上的两分钱，但我会将此标记为“过于宽泛”，因为人们可以写一本关于 MVC 实现主题的书（并且有些书）。
我同意你的团队：
为了限制依赖关系，视图甚至不应该知道控制器及其内部实现，因此它不能将创建的员工传递给控制器。
应该只有一个通知机制——委托或其他一些松散耦合机制——视图通知控制器，它应该创建一个新员工，或者不同的措辞：视图将通知控制器一些特定的输入或事件和控制器将决定创建一个新员工。
在您的解决方案视图中，控制器将紧密耦合在一起，实际上可以将其视为组件：MVC 模式将被破坏。
MVC 简而言之：模型持有数据，控制器持有逻辑，视图与用户交互。唯一知道彼此的组件是控制器。模型对视图或控制器一无所知，视图对模型一无所知，并且仅与控制器非常松散地耦合。只是通知它有关输入和类似的信息。您当然可以创建其他构造，但这不再是 MVC。你的问题是关于 MVC 的。
这里描述的是 Cocoa 中的 MVC 模式，词汇可能不熟悉，但 MVC 或多或少应该是这样的。绿色表示控制器对模型和视图的了解，而黄色表示不同的松散耦合机制。这可能在不同的语言和框架中被称为不同的。
在这里找到：什么应该拥有 MVC 模式中的模型？