摘要ActiveRecord属性

抽象ActiveRecord属性而不进一步标准化数据库的最佳方式是什么？摘要ActiveRecord属性

例如，假设有一列zip_code和方法命名addresses数据库表以确定邮政编码是有效的：

class Address < ActiveRecord::Base 
    def zip_code_valid? 
    .. 
    end 
end

我宁愿：

class Address < ActiveRecord::Base 
    .. 
end 

class ZipCode 
    def valid? 
    .. 
    end 
end

当我执行Address.find(1).zip_code时，它返回一个ZipCode与一个字符串。我不想通过创建一个名为zip_codes的表来标准化数据库。这个例子是假设的，我目前还没有真实的例子。我只是想知道我怎么可能做到这一点。

谢谢。

来源

2011-05-06 Andrew Ferk

我不确定你为什么想要做这正如你所讨论的ZipCode，但要回答你的问题，你应该考虑使用Rails聚合。

这里的文档：

http://api.rubyonrails.org/classes/ActiveRecord/Aggregations/ClassMethods.html

如果您有关于你要完成的事情，具体的问题，让我知道，我可以尝试回答这些具体问题。

来源

2011-05-06 18:01:50

谢谢。地址和邮政编码的例子就是一个例子，我很快就想到要解释我想要做什么。我正在试图找到抽象ActiveRecord属性的最佳方法，而不用进一步标准化数据库。我会看看你链接到的文件。 – 2011-05-06 18:18:30

我尽量多。我已经做了许多次相同的事情，用一个例子来解释起来更容易，但有时候很难想出一个容易描述的例子。我希望你能在Aggregations中找到你想要的东西。如果您有任何问题，请告诉我。 – 2011-05-06 18:20:37

如果你不打算在街道，门牌号码，城市等等做同样的事情，我不认为抽象出一个类的邮政编码是有意义的。你已经把它作为一个单独的列在地址表，因此将它存储在自己的类中（从ActiveRecord的角度来看）是没有意义的。另外，如果你将邮政编码存储在他们自己的表格（以及班级）中，你会得到什么？在我看来，如果在一个单独的类/表中保留单个属性太过分了，因为它是当前所处理的聚合的一部分。

来源

2011-05-06 17:46:41 McStretch

谢谢。这是一个关于将抽象推到边缘的假设性问题。昨天晚上，我正在阅读Code Complete和抽象数据类型部分，这个问题在我脑海中浮现。虽然它可能会太过分，但我们假设将来会有几十个只与邮政编码相关的方法，在这种情况下，我相信将方法抽象为ZipCode vs Address是有益的。 – 2011-05-06 18:04:19

如果你打算对这个问题作出判断，你至少应该首先提供一个答案。 – 2011-05-06 18:05:18

@jesse - 你在开玩笑吧？你意识到我确实提供了一个答案吗？我的回答是，他应该坚持他提供的第一个例子，而不是将它抽象为自己的类。另一位选民意识到并投票给我。很明显，如果我为了避免将邮政编码放入自己的班级而为他提供了一个深入的答案，我就会读到这个问题。 – McStretch 2011-05-06 18:08:58

摘要ActiveRecord属性

回答

相关问题