2つのモデル間の多対多のリレーションシップを整理する場合、人類の進歩的な部分は、オプション
:through => :join_model_name
使用して結合テーブルと
has_many
メソッドを使用することを
has_many
ています。 2つのActiveRecordオブジェクト間の各関係は、ActiveRecordオブジェクトです。
結合テーブルでは、オブジェクト間の関係に関する追加情報を含む便利な(いわゆる「追加」)フィールドを作成できるため、これは素晴らしいことです。
問題は、これらの追加の属性にどれだけうまくアクセスできるかです。
すべてのスクリーンキャストと本は、運がよければ簡単な例で動作します。 たとえば、
Articleモデルと
Categoryモデルはフレンドです。 もちろん、結合クラスの場合、
Categorizationまたは
ArticleCategorizationという名前が直感的にわかります。

したがって、2つのオブジェクト(
articleと
category )があり、それらの関係を具体化するARオブジェクト(またはオブジェクト)を見つけたい場合、純粋な心を持つ本の著者はこれを行うことを提案します:
relations = article.article_categorizations.find_by_category_id(category)
人生では、すべてがより複雑です。 多くの場合、モデルには長い複合名があります。または、モデル間にこのようなつながりがあり、各結合モデルの名前を発明すると小さな拷問になります。 モデルが
Articleと
Categoryではなく、
UserGroupと
Community 、または
Preorderと
CustomerNotificationであると想像してください。 バインディングモデルとは何ですか? 可能なオプション。
そのため、プログラマーは、プロジェクトのフレームワークで名前を標準化するように描かれています。 好みに応じてテンプレートが選択されます。例:
1)
FirstmodelSecondmodelRelation :
ArticleCategoryRelation 、UserGroupCommunityRelationまたは
2)
FirstmodelVsSecondmodel :ArticleVsCategory、UserGroupVsCommunity
3)...
最初のオプションを選択したとします。 次に、接続モデルのオブジェクトに到達するために何をしなければならないかを見てみましょう。
preorder, message = Preorder.first, CustomerNotification.first relations = preorder.preorder_customer_notification_relations.find_by_customer_notification_id(message)
つまり、「本のバリアント」は非常に冗長に見えます。 そして、私は次のようなものを見たいです:
preorder.relation_to(message)
同様に、対称的に反対方向に機能するはずです:
message.relations_to(preorder).where(:extra_field => "value")
そのような機能がRailsに実装されないのはなぜですか? 答えは簡単です。その名前とパラメーターにはリンクテーブルのヒントさえ含まれていません。また、2つのモデルの場合、プログラマーは好きなだけ多くの結合テーブルとリンクを作成できます。 どちらを検索する必要がありますか? -明確ではありません。
ただし、上記の2つの機能には、生存権と合理的な使用権があります。
経験が示唆するので:
1)ほとんどの場合、2つのモデルの間には、結合モデルが1つしかありません。 そして、それは計算することができます。
2)特にオブジェクトに追加の属性がある場合は、そのオブジェクトに頻繁にアクセスする必要があります。
3)結合モデルの長い名前を持つのは怖くない-それらがコードの可読性に影響しないなら。
Railsプロジェクトに2つのファイルを追加します。
/lib/ext/active_record/base.rbは
ActiveRecord :: Base拡張自体です
module MyExtensions module ActiveRecord module Base
/config/initializers/ext.rb
コードを簡素化する追加や修正があれば嬉しいです。
私はまた、「親愛なる、もっと簡単な方法があります、これをしてください:...」とコメントすることを嬉しく思います。