我试图谷歌这个，但我想要一劳永逸地回答。
我们正在讨论是否可以将业务逻辑放入模型中。
例如，如果要确保您的id在数据库中设置为int。你可以在模型课中做intval($id)吗？或者如果文字输入太短。或者你“必须”在控制器中做到这一点吗？
哪种方法正确？
对我来说，计算和其他你不想在模型中使用的东西（应该非常干净）应该在控制器中。
我很抱歉可能重复。
答案 0 :(得分：9)
胖模特，瘦小的控制者。
在你的模型中进行强制转换是很好的，因为那时你只能在一个地方进行，而不是在控制器中调用相关设置器的多个地方。如果您在十个不同的控制器中使用了十次设置器，那么您必须确保在十个不同的位置投射变量。
答案 1 :(得分：4)
不要担心将演员阵容转移到int。开始担心你显然对MVC的理解非常错误（不幸的是很多人都这样做）。模型就是一切。模型模型您的应用程序。该模型是一个自包含的块，表示您的应用程序所做的。
控制器只是让你的模型做某事的一种方法。它是外部世界和“你的应用程序”之间的粘合剂。控制器接收请求，并根据该请求决定模型应该做什么。然后要求视图可视化刚刚发生的事情或让用户了解模型的状态。
我通常会考虑这个结构：
该模型是最大的一块。它被分解为 primitives ，它们是表示应用程序中的一个 thing 的单个对象（类）（用户对象，post对象）; 服务，这是你可以做的事情（“注册用户”，“创建帖子”）;和存储/数据库，负责管理数据库中基元的存储/检索。它们如何协同工作以及您如何命名它们取决于您的应用程序，但这些是您通常需要处理的概念部分。
视图是它自己的图层，可能包含也可能不包含模板。
如您所见，这是应用程序需要完成的大部分工作，控制器是其中最小的部分。控制器主要接收输入，调用模型服务并指示响应时应呈现哪个视图。
想象出这种分离有意义的原因：问问自己如何使用应用程序。拥有一个用户可以做的东西的网站是典型的。但也许你也想拥有一个JSON API接口呢？还是管理任务的命令行客户端？这两种情况都需要不同的输入处理和不同的输出。但是“注册用户”和“创建帖子”是相同的操作，无论它们如何被调用。因此它们属于模型，您只需要稍微不同的控制器和视图来创建JSON API或CLI工具。在所有这些中，控制器确实是最小的部分，必须不包含业务逻辑。