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

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

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

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

  • 用户个人资料(属于用户)

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

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

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

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

有人建议使用多态关联。

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

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

关于我该怎么办的想法?


Helenr
浏览 471回答 3
3回答

动漫人物

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

慕侠2389804

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

相关分类

Ruby