MVC - 模型中的小逻辑？

Question

我试过用谷歌搜索这个，但我想要一个一劳永逸的答案。

我们正在讨论是否可以将业务逻辑放入模型中。

例如，如果您想确保您的 id 在数据库中设置为 int。那你能在模型课上做一个intval($id)吗？或者如果文本输入太短。还是您“必须”在控制器中执行此操作？

哪种方法是正确的？

对我来说，模型中不需要的计算和其他东西（应该很干净）应该在控制器中。

很抱歉可能重复。

Answer 1

胖模型，瘦控制器。

在你的模型中进行强制转换很好，因为你只在一个地方进行，而不是在多个地方调用控制器中的相关设置器。如果您在十个不同的控制器中使用了十次 setter，那么您必须确保在十个不同的地方转换变量。

Answer 2

不用担心在哪里对int 进行强制转换。开始担心您显然对 MVC 有非常错误的理解（不幸的是，正如许多人所做的那样）。模型就是一切。模型模拟您的应用程序。该模型是一个独立的块，代表您的应用程序做什么。

控制器只是让你的模型做某事的一种方式。它是外部世界和“您的应用程序”之间的粘合剂。控制器收到一个请求，并根据该请求决定模型应该做什么。然后要求视图可视化刚刚发生的事情或让用户了解模型的状态。

我通常是这样考虑结构的：

• 控制器
• 型号
  1. 服务
  2. 原语
  3. 存储/数据库
• 查看
  • 模板

模型是最大的块。它被分解为primitives，它们是代表应用程序中的一个事物的单个对象（类）（用户对象、帖子对象）； 服务，这是您可以做的事情（“注册用户”、“创建帖子”）； storage/database，它负责管理从数据库中存储/检索原语。它们如何协同工作以及如何命名它们取决于您的应用，但这些是您通常需要处理的概念部分。

视图是它自己的层，可能包含也可能不包含模板。

如您所见，这是应用程序需要完成的大部分工作，控制器是其中最小的部分。控制器主要接收输入，调用 模型服务 并指示应呈现哪个视图作为响应。

形象化为什么这种分离是有意义的：问问自己你将如何使用你的应用程序。拥有一个用户可以做事的网站是典型的。但也许你也想有一个 JSON API 接口呢？还是用于管理任务的命令行客户端？这两种情况都只需要不同的输入处理和不同的输出。但是“注册用户”和“创建帖子”是相同的操作，无论它们是如何被调用的。因此它们属于模型，您只需要稍微不同的控制器和视图来创建 JSON API 或 CLI 工具。在这一切中，控制器确实是最小的部分，不能包含业务逻辑。