Rails [新手向] 对 Controller 与 Model 体型问题的一些想法

jjym · 2012年06月26日 · 最后由 bluesky0318 回复于 2017年01月10日 · 7120 次阅读

写了点自己的看法


相信接触过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

共收到 7 条回复

贴过来会好点。

#1楼 @lanisle 恩,不太熟悉markdown.调下格式

UI逻辑可不可以写在helper?

@zgm UI逻辑可以放helper。 这些规则都是死的。用rails_best_practices去评估你的rails项目才是正道。

#4楼 @xds2000 这个好cool,我去好好看看,谢谢。

@xds2000 居然有这种东西,好神奇

这种说法还真的蛮贴切的,skinny controller and fat model.

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册