model-view-controller - 胖模型、瘦 Controller 和 MVC 设计模式

Question

我刚刚读了一篇blog post这可以用银行类比来解释 MVC。我有几个月使用 MVC 框架(CakePHP)开发 Web 应用程序的经验，所以我掌握了基础知识，但我开始看到一个主题，让我认为我在放置逻辑时采用了有缺陷的方法:

• 胖模型，瘦 Controller
• 在模型中保留尽可能多的业务逻辑

在我的应用中，模型患有厌食症，而 Controller 则肥胖。我在 Controller 中拥有所有业务逻辑，除了模型中的关联和验证规则之外没有任何内容。

通过扫描我的 Controller ，我现在可以识别出许多可能应该放入模型中的逻辑:

• 该应用程序有列表，其中包含项目，并且可以对项目进行排名。将列表按排名顺序排列的排序逻辑位于 Controller 中。
• 同样，元素(Item model)也有图像(Image model)。每个项目可能有一个默认图像(由项目表中的 image_id 指定)。当项目及其图像显示时，默认图像应首先出现。我有在 Controller 中执行此操作的逻辑。
• 显示列表时，相关列表会显示在侧边栏中。确定哪些列表相关的逻辑位于 Controller 中。

现在回答我的问题:

1. 根据我上面给出的示例，我是否认为这些是属于模型的 Controller 中当前的逻辑实例？
2. 哪些其他网络应用常见的逻辑领域应该纳入模型中？
3. 我确信识别这个问题并改变我的设计模式是成功的一半，但即使我决定采用上面给出的示例并尝试将该逻辑转移到模型中，我也不知道从哪里开始。任何人都可以通过在此处发布一些代码或链接到一些好的学习资源来为我指明正确的方向吗？ CakePHP 的特定帮助会很棒，但我确信任何 MVC 都足够了。

Answer 1

给你“正确”的答案有点困难，因为其中一些涉及框架的细节(无论你正在使用哪个)。

至少就 CakePHP 而言:

1. 是

2. 任何涉及数据或数据操作的内容都应该在模型中。就 CakePHP 而言，简单的 find() 方法怎么样？ ...如果它有可能做一些“特殊”的事情(即记忆一组特定的“条件”)，而您可能在其他地方需要这些，那么这是封装在模型方法中的一个很好的借口。

3. 不幸的是，从来没有一个简单的答案，代码重构是一个自然的过程。有时你一醒来就会想:“天啊通心粉……那应该在模型里!” (也许你不会这样做，但我有:))