如果我在数据库 User 和 Userinfo 中有两个表(为了规范化目的而拆分)，我会生成两个模型 User、UserInfo 并通过关系正常使用它们。
稍后，我的应用程序有一部分可以读取和写入两者，但是，在创建条目方面有相当多的业务逻辑，例如查找其他表的条件规则、字符串构建等。
创建第三个模型(非数据库支持的模型)来处理所有这些并通过其他两个模型创建/保存是否有意义？还是我应该将其保存在 Controller 中？
另一个示例可能是导入一个 CSV 文件，其中所有数据都在不同的表之间拆分，应用程序的其余部分使用单独的模型。我可以使用定义每一行的模型来处理通过其他模型保存导入的数据吗？或者这应该在 Controller 中吗？
我对开发大型 Rails 应用程序时的最佳实践很感兴趣。
最佳答案
听起来您正在规范化(最小化冗余)而不是反规范化。
我不知道你的应用程序，所以请把它作为考虑的事情而不是推荐的最佳实践:在这种情况下我通常喜欢做的是将 Userinfo 隐藏在 User 后面，这样 User 就是只有部分应用程序甚至知道有一个用户信息。这使代码的其他客户端( Controller 、其他模型以及您在控制台中与之交互时)保持简单、一致和 DRY。
引入第三个模型可能会达到同样的目的，但它也会增加应用程序的概念权重。
关于ruby-on-rails - Rails 胖模型示例，这是正确的思维方式吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5926756/