2

WebアプリケーションのMVC構造に関するいくつかの見解を聞いたことがあります。validates一部の人々は、モデルは非常に小さく、ActiveRecord（または他のORM）とandのような小さなものだけを含むべきだと信じている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、ユーザーにメッセージを配信するために使用できるようになります。これで物事は本当にきれいになりますが、私のモデルにはいくつかのロジックがあることに気づきました。言うまでもなく、モデルは別のモデルを作成します。

私が気にしないもう1つのアプローチは、通知を作成し、そのオブジェクトを介して送信することです。したがって、コントローラはNotification.new(:to => @user.id, ...)、を介してメッセージを実行して配信できますNotification.send。これにより、Notificationオブジェクトにロジックが組み込まれるため、自身を送信する方法がわかります。実際、Userモデルを使用して通知オブジェクトを作成するよりも、このアプローチの方が好きかもしれません。

複数のコントローラーからメッセージを送信するときに便利にするために、モデル内のこれらの小さなロジックを気にしません。これはそれについて行くための最良の方法ですか？より純粋な方法は、通知を送信する各コントローラーにNotificationHelperモジュールを含めることだと思いますか？

編集：私はモデルの「ドメインロジック」について少し読んでいます。これは奨励されているようで、notifyorsendメソッドはドメインロジックと見なされていると思います。MVCの経験がある開発者はこれについてコメントできますか？

4

1 に答える 1

0

2番目のアプローチでは、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など）

于 2012-10-30T19:14:37.607 に答える