Railsの名前空間モデル:組合の現状は?
-
03-07-2019 - |
質問
最初から、Railsは名前空間付きモデルに問題がありました。時間が経つにつれて、ほとんど誰もがそれを使うことをあきらめました。自分も含まれています。
Rails 2.3がリリースされたら、状況の更新をお願いします。私が念頭に置いている具体的な質問は次のとおりです。
- まず、行ってもいいですか?
- テーブルの命名、従うべきルールは?
- アソシエーション、最小の冗長性でアソシエーションを宣言するには?外部キー列の命名方法
- 自動要求、名前空間に一致するサブディレクトリにモデルファイルを配置すると機能しますか?または、ファイルの名前と場所を指定する方法
- 生成、モデルジェネレーターはネームスペースを正常かつ正しく処理しますか?
- 生成、コントローラを含むscaffoldジェネレータはどうですか?
- 注意すべき非互換性/気まぐれはありますか
解決
この問題に関して私が見た中で最高の記事は、からです。厳密に型指定なし。私の知る限り、2.3は問題を解決していません。つまり、まだ信頼性が低いということです。
他のヒント
最近、社内でこれについて大きな議論がありました。結局のところ、データベース内でテーブルの名前空間を作成できない場合、モデルの名前空間を作成しても意味がないと考えました。モデル(User、UserAddress、UserEmailAddresses)にプレフィックスを付けてユーザーディレクトリに配置し、次を使用することに決めました:
config.load_paths << "#{RAILS_ROOT}/app/models/users"
モデルをロードします。モデルの冗長性を制御するために、これを頻繁に行います:
has_many :addresses, :class_name => "UserAddress"
生成時には、あたかもネームスペースがないように作成し(スクリプト/生成モデルUserAddress)、ユーザーディレクトリに手動でコピーします。
肩をすくめ。最終的には、これが本当にあなたに与えるすべては、よりクリーンなディレクトリ構造であると思います。これは、私のようなVIMユーザーにとっては実際にはより厄介ですが、TextMatersにとっては素晴らしいことです。
私はまだそこから離れます。コードの簡潔さと明快さの面倒さや喪失を考慮すると、得られたもの(正直なところ何なのかわかりません)は間違いなく失われます。
私の最新アプリには87個のリソースがあり、あらゆる場所に管理機能が含まれています。名前空間の必要性はない、私見。