Rails:瘦控制器与胖模型,或者我应该让我的控制器厌食?

kon*_*ung 10 ruby controller model ruby-on-rails

我知道之前已经回答了类似的问题 - 例如:

  • 逻辑应该去哪里
  • 在哪里做某些任务等

但是我有一个更具体的问题 - 我应该在多大程度上采用这个公理:保持你的控制器瘦,让你的模特变胖!

这是一个例子:

例如,假设我有多个验证数据源.一个很好的例子是VIN号码 - 我可以对它进行验证,制造商数据源,DMV的数据源,以及我的本地数据库 - 看看我记录的内容.所以我有一个名为Vin和vins_controller的模型.在模型内部我有5种方法:

  • check_against_local_db
  • check_against_dmv
  • check_against_car_maker_1
  • check_against_car_maker_2等

在我的控制器中保持REST,在动作节目中 - 我有一个简单的case语句,它查看params [:source],并根据指定的源 - 将调用特定的check方法.

现在问题是:我应该保留控制在控制器中调用哪个数据源的逻辑,还是应该将其移动到模型中,然后在控制器中执行类似check_vin(source,vin)的操作?

我应该让我的控制器厌食吗?

编辑

我正在将此转换为来自@ jay-godse的官方回答(谢谢 - 当时这是一个很好的答案).自2010年以来,情况发生了很大的变化,这个问题仍然得到了一些看法 - 所以希望这会指出一些人正确的方向并帮助他们正确地组织他们的代码.

开拓者宝石 解决了问题中提出的问题.

Jay*_*dse 19

有一句老话,

智能数据结构和哑代码比其他方式更好地工作.

你所描述的一切都是关于一个数据如何与另一个数据相关.这本身就是你的线索,这些关系的逻辑,包括验证应该在模型或数据库层.

厌食控制器是精心设计(智能?)数据的标志.我的经验告诉我,您在设计数据方面付出的努力越多,整体编写的代码就越少.

控制器最好解析输入,调用适当的模型,然后格式化输出.


apo*_*ick 2

你应该尝试一下开拓者。这是一个基于 Rails 的瘦框架(实际上,它与所有 Ruby 框架一起运行),它引入了服务层、表单对象、持久性和域代码之间的间接性等等。

它确实有助于保持所有软件组件的精简,因为它为您提供了更多的抽象层,使您更容易弄清楚在哪里放置什么。

例如,当您有一个表单对象时,为什么要将验证逻辑压入控制器和模型中?