MVC 架构。模型中有什么？答案

【问题标题】：MVC Architecture. Whats in a model?MVC 架构。模型中有什么？
【发布时间】：2009-07-16 02:51:38
【问题描述】：

我是 MVC 的新手，但我已经看到了它的好处和优势。但是，我有一个（可能很容易回答）设计问题：

我一直在思考模型并讨论构建它们的正确方法。我看到它的方式有几个选项：

1) 模型和表结构具有一对一的关系...这意味着几乎每个表都有一个对应的模型。模型类具有与表列对应的属性，并具有所需的任何方法（如 getter 和 setter）以任何必要的方式操作表中的数据。这似乎是通用选项，我想我会让控制器根据需要调用模型来执行任何必要的业务功能。

2) 模型与业务逻辑的操作而不是数据更紧密地联系在一起：例如，如果在前端删除某个对象会影响多个表，那么模型会“建模”此行为并进行交互有几个表并执行必要的功能。然后，控制器只需为所需的任何业务行为调用单个模型。这不太通用，因为模型耦合得更紧密..但似乎实现起来更快。

3) 介于前两个选项之间。或者也许我完全没有抓住重点。

希望这是有道理的！如果我没有完全忽略这一点，我倾向于认为选项（1）更好。有什么想法吗？

编辑：没关系，但我计划使用 Codeigniter PHP MVC 框架。

【问题讨论】：

【解决方案1】：

两者都是有效的实现，并且可以根据您的需要运行良好。

您的#1 本质上是在描述 Active Record pattern，它被 SubSonic、Castle 和许多其他 ORM 实现所使用。

您的#2 本质上是在描述实体框架/休眠/LightSpeed 方法，在这种方法中，您正在处理在概念上与您的域相关的对象，而不是与表相关的对象。它们实际上包含其他域对象引用，而不是包含外键 ID 属性的对象，然后在访问时实例化这些引用。

两种方式都很棒。 Active Record 方法对于初学者来说通常更直观，并且潜在的陷阱更少。 EF风格可以省去很多基础编码，直接在代码中处理FK。

编辑：需要明确的是，您在这两种情况下所描述的都是与数据访问层相关的，而不是严格与模型相关的。但实际上您已经非常接近了，因为大多数模型倾向于简单地表示一种或多种这些类型的对象。

【讨论】：

【解决方案2】：

以上所有。

您使用的方法取决于您的设计理念。如果您更喜欢使用业务域来设计应用程序并将其驱动到数据库设计中，那么您更喜欢第二种方法。如果您喜欢先构建数据库，然后从数据库模式创建模型类，那么您喜欢第一种方法。这两种方法都是构建软件的有效方法。

【讨论】：

【解决方案3】：

1 号是要走的路。选项 2 确实是控制器的工作。例如，控制器然后获取模型并对它们执行操作，并将结果传递给视图。

这样想：

模型 = 您的数据

控制器 = 业务逻辑

查看 = 显示数据和操作

这非常简单，但是当我去设计一个系统时，这是我在脑海中想象的。

【讨论】：

哇，比我快几秒！ :-)
然后，repositories==数据访问层
不同意。如果您的模型有一个包含对 Boss 对象的引用的 Employee 对象，为什么您的模型在填充 Employee 时不获取两者，而不是让控制器手动填充 Employee？
我的意思是我不同意 #1 总是要走的路；）
我同意你的观点，有时你确实希望你的模型处理有意义的次要业务逻辑。我不得不说，在大多数应用程序中，很难严格遵守任何范式。

【解决方案4】：

将数据库视为模型，将业务逻辑视为控制器，将 UI 视为视图。这可能会有所帮助。这是一种过于简化的处理方法，但它使数据/行为分离大致正确。

【讨论】：

【解决方案5】：

我认为这不一定是非此即彼的情况。你的第一点是所谓的模型，但你的第二点听起来像一个视图模型，它通常是各种模型和模型的一部分的组合，它们将被发送到视图。当信息从 View 发回时，控制器负责进行组合和可能的分解。

【讨论】：