写了点自己的看法

---

相信接触过 Rails 的朋友们都知道 Skinny Controller, Fat Model 的说法

Skinny Controller, Fat Model 的说法出现在各大论坛和教程，帮助了很多初入 Rails 者放置自己的代码。

但是这种说法未免太过简洁。

可能新手偶尔会在一些细节上混淆，产生这些代码是放在 Controller 好些还是 Model 好些的疑问。

本文并非反对这种观点，而是讨论下什么情况下 Controller 需要减肥。

我认为 Controller 并非一直都应该皮包骨头，而且有时应该属于 Controller 的脂肪，初入者不应该仅仅抱着一句廋 Controller 胖 Model 就随便的丢到 Model 里面，而应抱着求知的心态去思考问题：

为什么要说胖 Model，廋 Controller? 这种说法适应于任何情况吗？

1.其实了解 MVC 思想就很容易理解第一点。

Model 是用来封装业务逻辑的，所以要尽可能的把涉及业务逻辑的代码放到 Model 里。

Rails 提供了 Model 中的验证即是个很好的例子。想象下，如果验证在 Controller 中，当你又要在另外的 Controller 中调用 Model 时，你可能需要把 Controller 中的验证代码再写一遍，而且现在你发现了一个 Bug，你需要在所有使用该 Model 的 Controller 中改代码！这带来的很高的维护成本和重复代码。

Controller 提供 View 中的数据，所以如果程序的 UI 逻辑发生了很大的变动，Controller 也有可能随之改变，现在你采用了胖 Model 廋 Controller 这种设计方式，因为业务逻辑都在 Model 中，Controller 仅仅是对 Model 的调用，我们只需要改动 Controller 中的几行代码即可。

2.其实我们了解了第一点即可理解这里

举个例子，说下我遇到的问题。

我需要在视图中取到多个 Tag 并插入数据库

在视图中我取到的是如下字符串：

Controller, Model, 代码设计，新手向

我需要将其 split 后分别插入数据库

经过思考后我把 split 和循环插入数据库的代码写在 controller 中

因为现在采用的是从一串字符串中截取每个 Tag，但若某天我修改视图层，用 Ajax 来分别获取每一个 Tag。

如果上述逻辑写在 Model 中这势必会需要修改 Model。

修改了下视图，却牵扯 Model。足以证明这种设计有问题，所以放在 Controller 才是正确的做法。

总结 如果说 Model 封装业务逻辑，那么 Controller 就是封装了 UI 逻辑。

Model 更接近数据库，Controller 更接近视图。

处理业务逻辑的代码应该放到 Model，牵扯到 UI 逻辑的应该放到 Controller

个人简单的判断方法

如果修改 View 时你的代码需要随之改动，那么把它放在 Controller 中

除此之外尽量放在 Model 中

如果这样你还是无法区分的话，至少记住一句话

Skinny Controller, Fat Model

md 颜色什么的不会搞。。懒得加粗什么的了，就这样吧 原文https://ruby-tips.herokuapp.com/posts/9