用户应该能够将一些图片发送给他的聊天伙伴（whatsapp / line style）。
可能还可以添加其他附件和视频。我们争论模型结构。我们使用 carrierwave 来管理文件。现在，用户只能发送图片，将来可能会添加一些其他数据类型。
相当标准的imo，有3个类（每个都有自己的DB表），每个类都有自己的载波上传器。
Chat::Picture
Chat::Video
Chat::PDF
这可能会更棘手一些。而不是3个模型，我们只有Chat::Attachment，我们使用 STI来定义类型。
Chat::Attachment::Picture < Chat::Attachment
Chat::Attachment::Video < Chat::Attachment
Chat::Attachment::Pdf < Chat::Attachment
这里每个班级都有自己的上传者。
所以问题：：这是使用STI作为设计模式的正确位置还是我们应该坚持常规的轨道模型？
答案 0 :(得分：0)
答案取决于您对未来的预期变化。如果您希望将来有更多更改，那么您应该采用常规方式。我个人不喜欢STI。我认为你最好不要在这里使用STI，rails会为你提供更好的关注点。在处理共享大部分相同功能和数据字段的模型类时，应考虑STI，但您作为开发人员可能希望对单独扩展或添加每个类进行更精细的控制。不是为多个表反复复制代码（而不是DRY）或放弃添加特殊功能或方法的灵活性，STI允许您在编写专用功能时使用将数据保存在单个表中。