让我先说这是我的第一个 live cakephp 项目。
我试图将逻辑从控制器移到模型中，但组件不可用的事实使这很尴尬。
例如，我想在用户注册后发送通知电子邮件。我已将电子邮件功能移至模型中，但现在必须将电子邮件组件导入模型中。
所以为了几行代码（不包括消息本身的字符串），我必须导入一个可能已经在控制器中使用的组件（虽然不是在这种特殊情况下）。
似乎蛋糕并没有真正为Fat Model概念“安排”？
【问题讨论】：
标签： cakephp
不要从模型发送电子邮件！ EmailComponent 是一个组件而不是一个行为是有原因的。模型是关于对数据进行建模。发送电子邮件与数据建模无关，它是关于与现实世界的交互，即输出，这就是该过程由组件和视图文件组成的原因。
如果你的 MVC 结构中的某些东西看起来真的很尴尬和奇怪，那么你可能做错了。
【讨论】：
find 是处理数据的一部分，所以它是一个模型函数。任何与您的数据本质上相关的东西都会进入模型，比如calculateTax 函数。在模型和用户/视图之间移动这些数据的任何东西，即与输入/输出和“流”有关的东西，都在控制器中。
“胖模型”概念并不意味着所有代码都应该移到模型中，我相信您已经知道了。在这种情况下，Cake 团队可能会提出论点——我认为是正确的——发送电子邮件是 application 逻辑的功能，而不是 business 逻辑的功能。如果您接受这个前提，那么任何邮件或消息传递功能都属于可用组件的控制器。
我总是这样想：
如果我要在我的应用程序中创建 API，我希望重用所有 业务 逻辑，但很少或不重用 应用程序 逻辑。如果有人通过 API 对我的应用程序执行操作，那么（通常，根据我的经验）直接向客户发送电子邮件不是我的应用程序的责任。他/她不知道他/她正在使用我的应用程序，因为它是通过外部资源访问的。更好的解决方案是执行业务逻辑，然后根据其完成能力让您的控制器（您的应用程序逻辑）发送电子邮件。
这不会消除每个用例的歧义，但它对我的大部分情况都有帮助。
【讨论】：
这是您的第一个项目，因此不必为盲目遵循“最佳实践”而烦恼。请记住，控制器的存在是有原因的 - 不仅仅是门口三明治中的空馅。
一旦启动并开始运行，您就可以根据自己的意愿进行审查和调整，并开始了解您可能希望将逻辑移入（或移出）模型的原因。
在最广泛的意义上，模型是应用程序与数据库的接口。在我看来，模型输出应该是数据，无论是纯数据（来自数据库）还是修改后的数据，仅此而已。
控制器对数据做一些事情。
视图显示控制器的输出。
【讨论】：