我应该在 Rails 应用程序（或任何 MVC 应用程序）中的哪里放置“通知用户”方法？

Question

我听说过一些关于 Web 应用程序中的 MVC 结构的观点。有些人认为模型应该非常小，并且只包含 ActiveRecord（或其他一些 ORM）和像 validates 和 belongs_to 这样的小东西，所以模型只有几行长。

我个人认为模型可以在应用中发挥更大的作用。例如，我需要在整个应用程序中频繁通知用户。通知可以从多个控制器触发。它们都根据用户的通知设置向用户发送通知，这是一个可通过用户模型访问的对象。

我想做类似的东西：

class User < ActiveRecord::Base
  #validations, relationships, etc

  def notify(event)
    notif = Notification.new
    notif.type = event.type
    notif.to = self.id
    # etc

    if notif.save
      # send the notification based on the settings
    end
  end
end

这将使任何控制器都可以使用@user.notify 将消息传递给用户。这让事情变得非常干净，但我意识到我的模型中有一些逻辑。更不用说这个模型制造了另一个模型。

我不介意的另一种方法是创建通知并通过该对象发送通知。因此控制器可以执行Notification.new(:to => @user.id, ...)，然后通过Notification.send 传递消息。这也会在 Notification 对象中添加一些逻辑，以便它知道如何发送自己。事实上，我可能更喜欢这种方法而不是通过 User 模型创建通知对象。

我不介意模型中的这些小逻辑，以便在从多个控制器发送消息时方便。这是最好的方法吗？我想一个更纯粹的方法是在每个发送通知的控制器中包含一个 NotificationHelper 模块？

编辑：我一直在阅读一些关于模型中的“域逻辑”的文章。似乎这是鼓励的，我想notify 或send 方法被认为是域逻辑。任何有 MVC 经验的开发人员都可以对此发表评论吗？

Answer 1

对于您的第二种方法，您可以使用 ActiveRecord::Observer

 class NotificationObserver < ActiveRecord::Observer
   def after_create(notification)
       # some sending logic
   end
 end

但不要害羞将小块逻辑提取到它们自己的类中，例如

lib/user_notify.rb

 class UserNotify
   def event_trigger(user,event)
       # some logic
   end
 end

使用适合您系统的命名概念（可能是 Notify.send_user_about_event 等）