猿问
下载APP

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

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

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

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

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

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

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

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

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

有人建议使用多态关联。

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

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

关于我该怎么办的想法?


慕仰1329654
浏览 41回答 3
3回答

眼眸繁星

当属性相同但行为不同时,将STI描述为最有用的是“关于正确”,但可能有一点限制。我喜欢使用STI,顾名思义,它是一种明确的OO风格的继承关系,而不是不同类型的对象之间的数据库风格关系。如果机器人和用户之间有共同的代码,我会说STI听起来像是赢家。如果只有一些共同的属性,它可能不太适用,但仍然值得一试。我是一个很有实验性的人,所以我的建议就是试一试。分支您的代码并将模型重构为STI关系。看看它是否真的干涸了,或者只是为了解决其他一些问题。有一件事我觉得你不会从控制器上看到很多好处。根据我的经验,STI模型通常不会转换为类似的相关控制器。但那将是另一种尝试的东西。有时会赢,有时则没有。

动漫人物

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

慕侠2389804

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