我陷入了一个奇怪的设计问题,
我正在研究两种类型的模型,
用户个人资料(属于用户)
其他在现场维护为"机器人"的人(不属于任何人)
这两种类型的配置文件的典型OO行为是相同的,但只有重要的属性/属性是常见的(非常重要的属性5-6),其他属性如"兴趣等"(几乎10-15属性)不存在用于bot配置文件
之前参与此工作的编码人员为机器人配置文件/用户配置文件创建了单独的模型/控制器,这在任何地方创建了大量冗余,并且预期难以维护,编写测试等.我想干这个,至少要解决一些/所有问题这些冗余问题.
有人建议使用单表继承作为解决方案
有人建议使用多态关联.
什么是更好的方法.我们什么时候实际使用STI？
我自己的想法是当模型的属性相同时,STI被最佳使用,并且它们的行为不同.
关于我该怎么办的想法？
当属性相同但行为不同时,将STI描述为最有用的是"关于正确",但可能有一点限制.我喜欢使用STI,顾名思义,它是一种清晰的OO风格的继承关系,而不是不同类型的对象之间的数据库风格关系.
如果机器人和用户之间有共同的代码,我会说STI听起来像是赢家.如果只有一些共同的属性,它可能不太适用,但仍然值得一试.
我是一个很有实验性的人,所以我的建议就是试一试.分支您的代码并将模型重构为STI关系.看看它是否真的干涸了,或者只是为了解决其他一些问题.
有一件事我觉得你不会从控制器上看到很多好处.根据我的经验,STI模型通常不会转换为类似的相关控制器.但那将是另一种尝试的东西.有时会赢,有时则没有.
我写过一篇关于这个主题的文章,包括一些与STI合作的技巧:
Rails中的单表继承
简而言之:对象之间需要有明确的OO风格的继承关系(由womble雄辩地说明),而不仅仅是一些共享数据.如果没有自然而明显的类层次结构,随着应用程序的发展,STI设计可能会变得难以维护.
其次,您应该考虑将所有数据放在一个表中是否很重要.使用多态关联,您的数据库查询将变得更加复杂,并且可能更慢.如果您计划在网站上列出所有对象(例如,在表格中),那么STI可能就是您的选择.
第三,确保您的子类没有太多的唯一属性.使用一个表中的所有数据,您不需要很多非全局列.这些不仅会占用空间(不是主要问题),而且会使数据结构混乱.如果您有"特殊"列,则应在代码中明确解释它们.
最后,如果您使用STI,我强烈建议您为所有子模型使用单个控制器.控制器的主要功能是提供对象的访问,如果需要以非常不同的方式访问对象,那么STI可能不是开始时的正确设计选择.
查看我的文章(上面的链接)以获取更多有用的提示.
我可能会使用STI或根本没有特殊功能.您可以将所有内容称为"个人档案",如果用户为零则您知道它是否为"机器人".您也可以在不使用STI的情况下存储"类型"字段.
某些事情会影响我使用STI的决定:
是否存在特定于机器人的逻辑
有多少机器人与用户配置文件(少数机器人意味着STI是好的 - 很多机器人,我可能会将它们存储在其他地方)
避免STI的原因有时会妨碍你.例如,将对象从一种类型更改为另一种类型(在这种情况下为Bot到配置文件)可能相当烦人.有时一个简单的"类型"字段更好.
值得注意的是,如果使用STI,您可能需要一个公共基类.所以,你可能希望Profile,BotProfile和UserProfile.这些名字取决于你.:)
京公网安备 11010802040832号 | 京ICP备19059560号-6 