1

ページが読み込まれるたびに、あるユーザーが別のユーザーを待っているかどうかをアプリケーションが確認する必要があるアプリケーションがあります。次のようなエントリがあります。

def self.up
    create_table :calls do |t|
      t.string   "user1_id"
      t.string   "user2_id"
      t.boolean  "active", :default=>false
      t.string   "meeting_url"
      t.string "embed_url"
      t.timestamps
    end

現在、アプリケーションは呼び出しテーブルをチェックして、ユーザー ID に一致する呼び出しがないかどうかを確認し、アクティブな場合は == true です。結果がある場合は、ユーザーに表示されます。問題は、ページをロードするたびに db 呼び出しが必要になることです。だから私の質問は次のとおりです：

1) これは最も効率的な方法ですか? (明らかに私は懐疑的です) 2) もしそうなら、最もドライな方法でこれを達成するにはどうすればよいですか?

どうもありがとう

デイブ

4

2 に答える 2

0

ユーザーがページの読み込みごとに待機している呼び出しがあるかどうかをアプリケーションが知る必要があり、その情報がデータベースにのみ保持されている場合は、はい、各ページでその情報をデータベースに照会する必要があると思います。ロード。

DRYnessに関する限り、RailsはMVCスタック全体に多数のメカニズムを提供し、物事をDRYおよび保守可能に保つことを保証します。

モデルでは、クラスメソッドをCallモデルに追加して、待機中の呼び出しをクエリするためのロジックをカプセル化できます。次のようになります。

class Call < ActiveRecord::Base

def self.awaiting_for_user user
    self.all(:conditions => ['user_id = ? AND active = true', user])
end

このようなメソッドにクエリをカプセル化することで、その情報をクエリするための基になるロジックが変更されても、そのメソッドの呼び出しが変更されないようにします。

このメソッド呼び出しを各コントローラーアクション（index、showなど）に追加する代わりに、コントローラーのbefore_filter / around_filter / after_filtersメソッドを使用して、コントローラー/アクションのセットでこのコードを実行できます。 

class ApplicationController
    before_filter :load_current_user
    before_filter :load_current_users_calls

....
protected

    def load_current_user
        # You could encapsulate this method in your User model
        @user = User.find(session[:user_id])
    end

    def load_current_users_calls
         @calls = Call.awaiting_for_user(@user)
    end

：exceptや：onlyなどのbefore_filterオプションを使用して、特定のコントローラーアクションでのフィルターの使用を特定します。また、ApplicationControllerで実際のload_current_users_callsメソッドを宣言すると、サブクラス化された各コントローラーにそのメソッドが含まれるようになりますが、ApplicationControllerにbefore_filter宣言を配置する必要はありません。before_filterを実行する任意のコントローラーを配置できます。

また、ビューレイヤーでは、@callsを標準レイアウトで簡単に表示するために部分的に作成できます。次のようなものをレイアウトに追加できます。

<%- if @calls && !@calls.blank? -%>
<%= render :partial => 'awaiting_calls_display', :locals => {:calls => @class} =%>
<%- end -%>

または、それがレイアウトに合わない場合は、該当するビューから呼び出すことができます。

于 2009-10-31T20:34:46.570 に答える
0

このモデルは、私には少し混乱しているように感じます。特に、user1_idとuser2_idは、私の内臓に不快感を与えます。これは、誰が誰を待っているかはあまり気にしないこと、2 人のユーザーに違いはなく、喜んでチェックしていることを示しています。ユーザーを検索するたびに「OR」を含む2つの列。これは、Rails と SQL の両方にとって混乱です。

また、あなたが説明しているビジネス上の問題でもありません。この 2 人のユーザーの関係は、完全に対称的ではありません。一方が他方を待っています。どちらがどれであるかは明らかに気にしますが、それをモデル化しているわけではありません。または、もしそうなら、あなたはそれらに不十分な名前を付けています.

これからあなたのアプリケーションを正確に把握することはできませんが、おそらくこれをクリーンアップするために次の 2 つのことを行います。

  1. これらのユーザー フィールドを非対称の関係 (発信者と受信者など) に絞り込みます。それらをcaller_idおよびcallee_idと呼ぶことができます。なんでもいい。次に、各セッションはcallee_idフィールド (私が思うに) をチェックして、誰かがそのユーザーを待っているかどうかを確認するだけで済みます。それで十分かもしれません。その場合は、ステップ 2 を気にしないでください。

  2. その「待機中」の関係を、高速な書き込みと削除用に最適化された別の単純なモデルにプッシュします。誰かが他の誰かと通話を開始しようとすると、受信者をキーとする待機ストアに書き込みます。おそらく、データベースの代わりにmemcachedを直接使用するでしょう。そうすれば、実質的に遅延がなく、頻繁な読み取りと更新によって他の操作が滞ることはありません。(または、使用しているデータベース テクノロジによっては、これは、メモリ ベースのテーブルが要求されるまれなケースの 1 つになる可能性があります。)

データを最初に考え、コードをテーブル構造に合わせようとしているように思えます。これは Rails には最適ではありません。まず自分の行動について考え、ユーザーに実行してもらいたいことにデータ モデルを適応させます。

于 2009-10-31T20:10:08.620 に答える