Rails胖模型的例子，这是正确的思维方式吗？

Question

如果在DB用户中有两个表和Userinfo (为规范化目的而拆分)，我将生成两个模型用户UserInfo，并通过关系将它们作为正常使用。

稍后，我的应用程序中有一个部分可以读写这两个部分，但是，在创建条目方面有相当多的业务逻辑，例如查找其他表以获取条件规则、字符串构建等。

制造第三个模型(一个非数据库支持的模型)来处理所有这些并通过另外两个模型创建/保存是否有意义？还是我应该把这个放在控制器里？

另一个例子可能是导入CSV文件，其中所有数据都被分割在不同的表中，这些表是应用程序其余部分使用的独立模型。我是否可以使用定义每一行的模型来处理通过其他模型保存导入的数据。还是再一次应该在控制器里？

我对开发大型rails应用程序时的最佳实践很感兴趣。

Answer 1

听起来你是在正常化(最小化冗余)，而不是去正常化。

我不知道您的应用程序，所以请将此作为需要考虑的内容，而不是推荐的最佳实践:在这种情况下，我通常喜欢做的是将Userinfo隐藏在用户后面，这样用户才是应用程序中唯一知道有Userinfo的部分。这使得代码的其他客户端(控制器、其他模型和您在控制台中与其交互时)保持了简单、一致和干燥。

引入第三种模型可以达到同样的目的，但它也增加了应用程序的概念权重。

Answer 2

答案取决于为什么首先将用户数据分成两个表--它应该解决什么问题。找出这一点，并尝试将相同的逻辑应用于模型。

无论如何，我同意创建第三个模型是有意义的，它封装了与另外两个模型一起工作的复杂性。这使您可以向应用程序的其他层(控制器、视图)提供一个更简单的接口。然而，你必须仔细观察你在这件事上的进展。如果您发现自己重新实现了ActiveRecord::Base的大部分，将调用委托给封装的组件，那么可能是重新考虑的时候了。

顺便说一句，你所做的不是去正常化。关系数据库上下文中的非规范化意味着创建冗余(请参阅维基百科关于标准化的文章，反规范化正好相反)。这样做通常是为了通过减少所需的联接量来提高性能。