1

レールのソーシャルリンクシステムに関する多くのチュートリアルを見ています。結合モデル「友情」を使用して、ユーザーオブジェクトのエイリアスとして友人を一貫して使用しているように見えることに気付きました。

最初はこれに従っていましたが、先に進むにつれて、物事がcreate.friend本当に鈍くなっているようです。私の例では、「連絡先」と「接続」という用語を使用しています...ユーザーの連絡先をすべてリストするときは、連絡先コントローラーとビュー ( /contacts 、 /contacts/検索、/連絡先/作成など..) しかし、すべてのクラッドは実際には接続 (友情) テーブルを扱っています... これは、私が行くにつれて本当に後方に見え始めます.

なぜこのように行われるのですか？私が思う唯一の利点は、「contact.email」のようなものを言うことができることですが、コードに追加の抽象化と体操がそれに値するかどうかはわかりません。私は言うのと同じくらい幸せだろうcontact.user.email.

連絡先ページにリンクしますか? link_to contact.user（右？）

モデルが標準的で明白な粗雑な構造と「接触」し、ユーザーモデルのこのエイリアシングを忘れた場合、何か問題はありますか? 率直に言って、認証以外の目的でユーザー モデルをいじってもあまりメリットはないと思います。ユーザーのすべての情報をプロファイルに入れています。

または、何か不足していますか？

更新: 不明な点があるようですので、詳しく説明します。

プランA: 

def contact
 belongs_to :user
 belongs_to :connection, :class_name => 'User', :foreign_key =>'contact_id'
 validates_uniqueness_of :contact_id, :scope => :user_id, :message => ' allready one of your contacts.'
 attr_accessor :invite
end

次に、これに対して通常の CRUD を実行します。「連絡先」ページに移動すると、通常のcrud操作などですべての連絡先が表示されます...連絡先の電子メールを取得するには、このシナリオでは次のように言います: contact.connection.email

それから私はいくつかの読書をしました、そして他の誰もがこれをしているのを見ました：

class Connection < ActiveRecord::Base

  belongs_to :user
  belongs_to :contact, :class_name => 'User', :foreign_key =>'contact_id'

  validates_presence_of :user_id
  validates_presence_of :contact_id
  validates_uniqueness_of :contact_id, :scope => :user_id, :message => ' allready one of your contacts.'

  attr_accessor :invite
  end

しかし、連絡先コントローラー (フレンド コントローラー) を使用して、ここでクラッドを渡します。唯一の利点は、contact.email と言うことができるように見えることですが、連絡先コントローラーのすべてのクラッドを奇妙なものにします。例えば：

http://railsforum.com/viewtopic.php?id=16760

なぜ明らかな切断が起こるのだろうと思っていました。

更新 2:

わかりました...連絡先はユーザーモデルへの参照でなければなりません...それを回避することはできません。その場合でも3ステップ。ただし、このパスに沿って実行しようとすると、いくつかの細かい点でまだ混乱しています。

次のようなコードでcontacts_controller.rbを使用するのはmvcの違反ですか？

  # in contacts_controller.rb
def destroy 
    @connection = Connection.find(params[:id])
    @connection.destroy

    respond_to do |format|
      format.html { redirect_to :action=>'index' }
      format.xml  { head :ok }
    end  
  end

そして、form_for @connection やルーティング エラーなどを実行しようとすると、おかしくなりました。私はこの質問を台所で沈めていることを知っており、これまでのすべてのフィードバックに本当に感謝しています.

更新 3:

これらの関係で私が抱えている混乱の実際的な例を次に示します。

<% @contacts.each do |contact| %>
    <li><%= contact.email %> <%= link_to 'Remove Contact', contact.connection, :confirm => 'Are you sure?', :method => :delete %></li>
<% end %>

ユーザーの連絡先を反復処理するとき、この連絡先を削除対象のリストに表示する接続を巧みに呼び出すにはどうすればよいですか? たぶん、ユーザーの接続を反復処理して、connection.contact.email をプルして電子メールを表示する必要がありますか?

4

2 に答える 2

1

私はあなたの質問に完全に従うかどうかはわかりませんが、うまくいけば、これがあなたの質問に答えるのに十分であり、より答えやすい方法で投稿することを願っています.

友情関係を結合モデルとしてモデル化する理由は、「私があなたと友情を持っているからといって、あなたが私と友情を持っていることを意味しない」という限り、友情には方向性があるからです。私があなたと友情を築く場合を考えると、あなたが友情を確認し、反対方向を指す関連付けを作成するまで、必ずしも有効ではありません.

友情を別のエンティティとしてモデル化するもう 1 つの理由は、モデルを充実させることができるため、その人物をどのように知っているか、またはあなたを紹介した人物へのリンクを含めることもできます。

モデルを作成するときは、必ずしもコントローラーと 1 対 1 であると考えるべきではありません。リソースはモデルから分離されています...

多くのアプリケーションでは、ユーザー モデルとプロファイル モデルがあります。多くの場合、これらは 1 対 1 の関係にあり、なぜ 1 つのエンティティとしてモデル化されていないのか疑問に思う人も少なくありません。正直なところ、できない具体的な理由はありません。同じエンティティとしてモデル化しますが、それらを分離しておくことにはいくつかの利点があります。まず、プロファイルを削除せずにユーザーのログイン資格情報を削除できます (これは、誰かがアカウントを削除したいが、コンテンツを削除したくない/する必要がない場合に最適です)。たとえば、Facebook アカウントを削除し、タグ付けされた写真には引き続きあなたの名前が表示されますが、プロフィールへのリンクは表示されません (これが実際にどのように機能するかはわかりませんが、これは単なる例です)。 .. これは「グッド プラクティス」であり、アプリケーションの保守が容易になることを願っています。

これが少し役立つことを願っています。さらに質問がある場合は、コメントを残してください。この投稿を更新します。

于 2011-03-08T20:32:00.380 に答える
0

参加モデルが存在する主な理由の 1 つは、ユーザーが複数の人の友達になることができることです。ユーザーが多くの連絡先を共有することを期待していない場合は、結合を削除します.

于 2011-03-08T20:10:30.283 に答える