2

モデルの名前空間をネストした方がよい場合と、それらをすべてトップレベルのままにしておく方がよい場合についてのガイドラインは何ですか?

たとえば、いくつかのクラスがすべて 1 つのコア クラスと関係がある場合 (そして、システムの大部分がそのコア クラスのみを処理する場合)、私の本能はそれらを次のように宣言するように指示します。

CoreModel

CoreModel::DependentOne

CoreModel::AnotherDependent

ほとんどの場合、これは has_many/belongs_to の関係に対応します (これは、構成よりも慣例の次の候補であると考えています。)

繰り返しますが、私のルートはしばしばこのネストを反映しています: /CoreModels/:core_model_id/DependentOne/:id

これを行う必要があると私が考える理由は、同じ大規模アプリケーションの 2 つのコンポーネント領域が、ソフトウェアの他の領域と同じではないにしても、類似した名前のサポート コンポーネントを必要とすることがよくあるからです。これらの依存モデル (そのコア モデルをサポートするためだけに存在する) に名前を付けるのが最善の方法だと思います。

この方法で物事を行うと物事が簡単になることがありますが（DependentOneモデルのみを取得する必要があり、自動的に正しくルーティングされるlink_toなど）、form_forなどの他の項目は適切に機能しないため、混乱しています（そうではないため）適切にルーティングし、CoreModel を form_for に追加すると、core_model_core_model_dependent_one などのルートがないことについて不平を言います....

おそらく私は十分に明確になっていないので、明確化の要求が来たらこれを更新するようにします.

4

1 に答える 1

2

...the majority of the system only deals with that core class...

その場合、名前空間を気にしません。

The reason I feel like I should do this is because often two component areas of the same large application may need a supporting component with similar if not identical names as other areas of the software. I feel like name spacing these dependent models (which only exist to support that core model) is the best way to go.

ビンゴ - 名前の競合がある場合、ネームスペースはそれを修正する良い方法です。しかし、あなたはまだその問題を抱えていますか？

名前空間は名前の競合を防ぎますが、Rails ではいくつかの落とし穴や頭痛の種が発生し、(アプリ全体で) かなり多くのタイピングが発生します。したがって、実際に名前の競合がない限り、私には価値がありません。

このような構造を考えてみましょう。コア モデルと、それを支援する多くのモデルがあります。

#Core Models
Model
Supporter
Assister
Helper
Benefactor

アプリの寿命のほとんどの間、問題が発生することはありません。最終的にヒットした場合は、次のようにすることができます。

AltModel
AltModel::Supporter    
OtherModel
OtherModel::Benefactor

または、クラス名のプレフィックスを付けるだけで本当に簡単な場合は、次のようになります。

AltModelSupporter
OtherModelBenefactor

さらに言えば、コアモデルに「適切に」名前空間を付けるよりも、この方法でコアモデルに名前を付ける方がおそらく簡単です。

CoreModel
CoreSupporter
CoreAssister

そのため、必要なことを達成する方法はたくさんありますが、実際に名前空間の競合がない場合は、アプリのコア機能の名前空間を気にするべきではないと示唆する方法はありません。既に遭遇した頭痛の種を考えると、アプリのコア モデルを最上位の名前空間に残し、実際に競合する別のモデルのみを入れ子にする方が満足できると思います。

于 2012-04-24T13:10:40.177 に答える