MVC - 模型小逻辑？(MVC - small logic in model?)

我试图谷歌，但我想要一个答案一劳永逸。

我们具有的工作，你是否可以把业务逻辑模型的讨论。

例如，如果你想确保你的ID在数据库中设置为int。你可以做一个intval($id)模型类呢？或文本输入太短。还是你“不得不”在控制器做什么呢？

这是正确的方法是什么？

对我来说，事情如计算，你不希望在模型中的其他东西（应该是很干净的），应在控制器。

我对可能重复的遗憾。

Answer 1:

不要担心在哪里做造型为int 。开始担心，你显然有MVC的一个非常错误的认识（如许多人一样，很遗憾）。该模型就是一切 。该模型的模型应用程序。该模型是一个自包含块，表示您的应用程序的功能。

控制器仅仅是一个办法让你的模型做一些事情。这是外面的世界，“你的应用”之间的胶水。该控制器接收到一个请求，并基于该请求的决定模型应该做的事情。然后该视图被要求想象刚刚发生了什么或给用户一些洞察模型的状态。

我通常认为结构在此方面：

调节器
模型
1. 服务
2. 原语
3. 存储/数据库
视图
- 模板

该模型是最大的一块。它被分解为原语，它们是单独的对象（类），其代表在应用程序（用户对象，交对象）的一件事 ; 服务，这是你可以做 （“注册用户”，“创建后”）的事 ; 和存储/数据库 ，它负责从数据库管理原语的存储/检索。他们究竟是如何协同工作，如何准确你他们的名字取决于你的应用程序，但这些通常需要处理概念的部分。

该视图是其自身的层，其可以或可以不包含模板。

正如你看到的，这是大多数应用程序需要做的工作，控制器是它的最小部分。大多接收输入时，控制器调用一个模型服务 ，并指示哪个视图应当响应被渲染。

为了形象化为什么这种分离是有道理的：问问自己，你打算如何使用你的应用。有一个网站上，用户可以做的东西是典型的。但是，也许你也想有这方面的JSON API接口？或命令行客户端管理任务？这两种情况只是需要不同的输入处理和不同的输出。但是，“注册用户”和“创建一个帖子”相同的动作，不管他们是如何被调用。因此，他们属于在模型中，你只需要创建一个JSON API或CLI工具稍微不同的控制器和视图。在所有这一切，控制器真的是最小的一部分，并且不得包含业务逻辑 。

Answer 2:

脂肪模型，瘦控制器。

这是细做铸件的模型，那么你只能做在一个地方，不是你叫的初步认识二传手在控制器中的多个地方。如果您在十个不同的控制器使用的二传手十倍，那么你必须确保你在十个不同的地方被铸造变量。