ruby-on-rails - 学习基础 rails : Where to put conditional business logic?

Question

所以我试图自学 Rails，但在弄清楚逻辑走向时遇到了一些麻烦。 在我的练习中，我有一个支付模型。 类(Class)广场 整数 Product_Type 字符串产品名称

处理付款有规则 如果 product_Type 是物理的，那么做这个，如果是虚拟的，那么做那个 如果 product_name 是书，则执行此操作 如果 product_name 是奶牛，就这样做

我想不通的是将这些规则放在哪里。 我是否在模型中创建了一个名为 process 的方法来运行这些规则？这个 go 逻辑是否进入 Controller ？我只是不清楚。

如有任何见解，我们将不胜感激。

谢谢

Answer 1

你绝对应该在模型中保留这个逻辑，事实上，如果不同类型之间的逻辑明显不同，你应该使用具有单表继承的多个模型。

参见: http://joemcglynn.wordpress.com/2009/12/11/rails-sti-part-1/ http://joemcglynn.wordpress.com/2009/12/12/rails-single-table-inheritance-part-2/

基本上这个想法是这样的:您已经定义了产品类型——“类型”列是 STI 表的主要特征。

有了 STI，您将拥有多个非常相似的模型，而不是拥有一个包含大量条件逻辑或多个模型的模型，这些模型具有非常相似的数据，但逻辑有些不同，因此所有这些相关模型都可以共享同一个表，并继承自一个普通的类。

例如:

class Product < ActiveRecord::Base
  ...
  common logic goes here
  ...
end

class PhysicalProduct < Product
  ...
  physical-product-specific logic goes here
  ...
end

class VirtualProduct < Product
  ...
  virtual-product-specific logic goes here
  ...
end

因此，通过这种方式，您可以创建类似 product.deliver 的方法，该方法在产品模型中默认定义为触发发送产品——但在 VirtualProduct 模型中被覆盖以触发电子邮件取而代之的是下载链接。

ActiveRecord 可以很好地处理所有这些(请参阅上面的链接文章以了解演练)，并且您的大部分表单、链接和 Controller 等将继续以与当前相同的方式工作。

通常，您总是希望在模型而不是 Controller 中保留尽可能多的逻辑，因为模型更易于测试和调试。在您的情况下，STI 是一种不错的方法将这种分支逻辑保留在模型中，而不是 Controller 和 View 中。