php - MVC - 模型中的小逻辑？

Question

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

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

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

哪个是正确的方法？

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

我很抱歉可能重复。

Answer 1

胖模型，瘦控制器。

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

Answer 2

不要再担心在哪里做演员表了int。开始担心您显然对 MVC 有非常错误的理解（不幸的是，正如许多人所做的那样）。模型就是一切。该模型为您的应用程序建模。该模型是一个独立的块，代表您的应用程序所做的事情。

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

我通常从以下方面考虑结构：

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

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

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

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

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