Rails 胖模型示例，这是正确的思维方式吗？
如果我在数据库 User 和 Userinfo 中有两个表（出于规范化目的而拆分），我会生成两个模型 User、UserInfo 并通过关系正常使用它们。
后来，我的应用程序中有一部分可以读取和写入两者，但是，创建条目有相当多的业务逻辑，例如查找其他表的条件规则、字符串构建等。
创建第三个条目是否有意义模型（非数据库支持的模型）来处理所有这些并通过其他两个模型创建/保存？或者我应该将其保留在控制器中？
另一个示例可能是导入 CSV 文件，其中所有数据都分割在不同的表和应用程序其余部分使用的单独模型之间。我可以使用定义每一行的模型来处理通过其他模型保存导入的数据吗？或者这应该在控制器中？
我对开发大型 Rails 应用程序时的最佳实践感兴趣。
If I have two tables in a DB User and Userinfo (split for normalisation purposes) I generate the two models User, UserInfo and use them as normal via relationships.
Later on I have section of my application that reads and writes to both, however, there is a fair amount of business logic on creating entries for example looking up other tables for conditional rules, string building etc.
Would it make sense to make a third model (a non-database-backed model) to handle all this and to create/save via the other two models? or should I keep this in the controller?
Another example could be importing a CSV file where all the data is split between different tables, separate models as used by the rest of the application. Could I use a model defining each row that handles saving the imported data via the other models. Or again should this be in the controller?
I am interested in the best practices when developing large rails applications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来你正在标准化（最小化冗余）而不是反标准化。
我不了解您的应用程序，因此请将此视为需要考虑的事情，而不是推荐的最佳实践：在这种情况下，我通常喜欢做的是将用户信息隐藏在用户后面，以便用户是唯一的部分应用程序甚至知道有一个用户信息。这使得代码的其他客户端（控制器、其他模型以及您在控制台中与之交互时的您）保持简单、一致和干燥。
引入第三个模型可能会达到相同的目的，但它也增加了应用程序的概念权重。
Sounds like you're normalizing (minimizing redundancy) rather than de-normalizing.
I don't know your application, so please take this as something to consider rather than a recommended best practice: what I typically like do in a situation like this is hide the Userinfo behind the User, so that the User is the only part of the application that even knows there is a Userinfo. This keeps things simple and consistent and DRY across the other clients of the code (controllers, other models, and you when you interact with it in the console).
Introducing a third model might serve the same purpose, but it's also adding conceptual weight to the application.
答案取决于您为什么首先将用户数据拆分为两个表 - 它应该解决什么问题。弄清楚这一点并尝试将相同的逻辑应用于模型。
无论如何，我同意创建第三个模型来封装与其他两个模型一起工作的复杂性是有意义的。这使您可以向应用程序的其他层（控制器、视图）呈现更简单的界面。然而，你必须仔细观察你能做到什么程度。如果您发现自己通过委托对封装组件的调用来重新实现大部分 ActiveRecord::Base，那么可能是时候重新考虑了。
顺便说一句，你所做的并不是去规范化。关系数据库上下文中的反规范化意味着创建冗余（查看关于规范化的维基百科文章 ，反规范化则相反）。这样做通常是为了通过减少所需的联接数量来提高性能。
The answer depends on why you split the user data into two tables in the first place - what problem was it supposed to solve. Figure that out and try to apply the same logic to the models.
In any case, I agree that it makes sense to create a third model that encapsulates the complexity of working with the other two. This lets you present a simpler interface to other layers of the application (controllers, views). However, you'll have to watch carefully how far you're going with this. If you find yourself re-implementing most of ActiveRecord::Base by delegating calls to your encapsulated components, then it may be time to reconsider.
BTW, what you did isn't de-normalization. De-normalization in the context of a relational database means creating redundancy (check out the Wikipedia article on normalization, de-normalization is the opposite). This is usually done in order to improve performance by reducing the amount of joins required.