我应该担心在rails模型中重用方法吗？

Question

很久以前，我了解到你应该在模型上编写可重用的方法，这样你就不会在应用程序中找到重复的代码。当然，这是使用PHP，它不像ruby那样动态。

现在，我正在使用Rails设计API，我仍然在考虑这个问题。所以，我的问题是：我应该创建方法User.login(user, password)还是应该使用User.find_by(user: user, password: password)？

我过去也喜欢方法方法，因为它提供了一些设施，就像上面的方法登录一样。 password通常应该以某种方式加密，通过创建login方法我可以封装它。

你们有什么想法？

Answer 1

通常，您希望在对象上定义方法并从其他对象中调用它们。这是面向对象编程的关键租户：消息传递。在对象上调用方法允许该对象处理其自己的内部。如果可能的话，你不想操纵或查询另一个对象的内部。否则，当您更改该对象的内部时，您现在必须更改依赖于这些内部的所有代码。

为了说明使用您的示例，如果您有一天将用户模型的密码属性（即列名称）更改为encrypted_password，那么User.login(user, password)方法就不会需要改变，但User.find_by(user: user, password: password)方法会。所以这就是创建脆弱的代码！

Be DRY, Shy, and tell the other guy！

更新

在Rails中，你会发现人们经常使用Rails＆＃39; Active Record Query Interface用于替换对象上的常用函数，如基于多个属性的getter和setter。这通常被认为是正常的，因为例如，大规模分配可以大大简化您的代码。因为在某种程度上，User.find_by(user: user, password: password)实际上是传递给User类的消息。我同意你对此的担忧，并认为通常至少应该定义一个命名的范围来处理这个问题。和/或创建用于构建对象关系的类方法应该经常使用（例如，参见this SO answer我在这个主题上写了一段时间）。构建Rails模型关系时只是有点松散。我认为这可能来自两件事：1）DHH（Rails的创建者）在纯对象建模概念和代码的简单性/可读性的抽象上并不是很大，2）我认为在一开始大多数Rails应用程序是一种玩具应用程序，人们习惯于不考虑过于强烈地设计它们。但是，无论哪种方式，根据您自己的舒适程度做出您认为正确的事情，并进行权衡。

Answer 2

都不是。你几乎肯定想要使用像devise这样的宝石来为你提供这些方法。