单表继承以及在Rails中使用它的位置

Question

单表继承以及在Rails中使用它的位置

我陷入了一个奇怪的设计问题，

我正在研究两种类型的模型，

• 用户个人资料（属于用户）

• 其他在现场维护为“机器人”的人（不属于任何人）

这两种类型的配置文件的典型OO行为是相同的，但只有重要的属性/属性是常见的（非常重要的属性5-6），其他属性如“兴趣等”（几乎10-15属性）不存在用于bot配置文件

之前参与此工作的编码人员为机器人配置文件/用户配置文件创建了单独的模型/控制器，这在任何地方创建了大量冗余，并且预期难以维护，编写测试等。我想干这个，至少解决一些/所有问题这些冗余问题。

有人建议使用单表继承作为解决方案

有人建议使用多态关联。

什么是更好的方法。我们什么时候实际使用STI？

我自己的想法是，当模型的属性相同时，STI被最佳使用，并且它们的行为不同。

关于我该怎么办的想法？

Answer 1

Rails中的单表继承简而言之：对象之间需要有明确的OO风格的继承关系（由womble雄辩地说明），而不仅仅是一些共享数据。如果没有自然而明显的类层次结构，随着应用程序的发展，STI设计可能会变得难以维护。其次，您应该考虑将所有数据放在一个表中是否很重要。使用多态关联，您的数据库查询将变得更加复杂，并且可能更慢。如果您计划在网站上列出所有对象（例如，在表格中），那么STI可能就是您的选择。第三，确保您的子类没有太多的唯一属性。使用一个表中的所有数据，您不需要很多非全局列。这些不仅会占用空间（不是主要问题），而且会使数据结构混乱。如果您有“特殊”列，则应在代码中明确解释它们。最后，如果您使用STI，我强烈建议您为所有子模型使用单个控制器。控制器的主要功能是提供对象的访问，如果需要以非常不同的方式访问对象，那么STI可能不是开始时的正确设计选择。

Answer 2

我可能会使用STI或根本没有特殊功能。您可以将所有内容称为“个人档案”，如果用户为零则您知道它是否为“机器人”。您也可以在不使用STI的情况下存储“类型”字段。某些事情会影响我使用STI的决定：是否存在特定于机器人的逻辑有多少机器人与用户配置文件（少数机器人意味着STI是好的 - 很多机器人，我可能会将它们存储在其他地方）避免STI的原因有时会妨碍你。例如，将对象从一种类型更改为另一种类型（在这种情况下为Bot到配置文件）可能相当烦人。有时一个简单的“类型”字段更好。值得注意的是，如果使用STI，您可能需要一个公共基类。所以，你可能希望Profile，BotProfile和UserProfile。这些名字取决于你。:)