多少节课太多了？铁路STI

Question

我正在开发一个非常大的 Rails 应用程序。我们最初没有使用太多继承，但我们从顾问那里获得了一些令人大开眼界的经验，并且正在寻求重构我们的一些模型。

我们的应用程序中有很多以下模式：

class Project < ActiveRecord::Base
  has_many :graph_settings
end

class GraphType < ActiveRecord::Base
  has_many :graph_settings
  #graph type specific settings (units, labels, etc) stored in DB and very infrequently updated.
end

class GraphSetting < ActiveRecord::Base
  belongs_to :graph_type
  belongs_to :project
  # Project implementation of graph type specific settings (y_min, y_max) also stored in db.
end

这也会导致视图、助手和 GraphSetting 模型本身中出现大量条件。这些都不好。

一个简单的重构，我们摆脱了 GraphType，转而使用更像这样的结构：

class Graph < ActiveRecord::Base
  belongs_to :project
  # Generic methods and settings
end

class SpecificGraph < Graph
  # Default methods and settings hard coded
  # Project implementation specific details stored in db.
end

现在这对我来说非常有意义，简化了测试，删除了条件，并使以后的国际化更容易。然而我们只有 15 到 30 张图表。

我们有一个非常相似的模型（例如，使用起来很复杂），大约有 100 种不同的“类型”，并且可能会增加一倍。他们都会有继承的关系和方法，其中一些需要重写比其他人更多的方法。这似乎是完美的用途，但这么多似乎太多了。

200 节性病课程很多吗？我们还应该关注另一种模式吗？

感谢您的智慧，我会回答任何问题。

Answer 1

如果差异仅在于班级的行为，那么我认为这应该不是问题，并且这是 STI 的良好候选者。 （请注意，我从未尝试过对如此多的子类进行此操作。）

但是，如果您的 200 个 STI 类每个都有一些独特的属性，则您将需要主表中的许多额外数据库列，这些列将为 NULL，其中 99.5%时间。这可能非常低效。

为了创建类似“多表继承”的东西，我之前成功做过的就是使用一些元编程来关联其他表以获取每个类特有的详细信息：

class SpecificGraph < Graph
  include SpecificGraphDetail::MTI
end

class SpecificGraphDetail < ActiveRecord::Base
  module MTI
    def self.included(base)
      base.class_eval do
        has_one :specific_graph_detail, :foreign_key => 'graph_id', :dependent => :destroy
        delegate :extra_column, :extra_column=, :to => :specific_graph_detail
      end
    end
  end
end

委托意味着您可以访问关联的详细信息字段，就好像它们是直接在模型上，而不是通过 special_graph_detail 关联，并且出于所有意图和目的，它“看起来”就像这些只是额外的列。

您必须权衡需要连接这些额外详细信息表的情况与仅在主表中包含额外列的情况。这将决定是使用 STI 还是使用关联表的解决方案，例如我上面的解决方案。