私は、今後数年間で大幅に成長する可能性がある MVC 4 プロジェクトをまとめています。白紙の状態から始めるという贅沢と挑戦により、コントローラーとビューのルーティングと整理のベスト プラクティスを見つけようとしています。
MvcCodeRouting NuGet パッケージは魅力的で、使用する予定です。ただし、MVC エリアを利用することも賢明かどうかはわかりません。MvcCodeRouting が使用されている場合、MVC Areas は不必要なように見えますが、Areas によって提供される余分なコード編成が依然として望ましいかどうかはわかりません。
私の言いたいことを説明するために、この架空の採点アプリケーションを見てみましょう。次の高レベルの領域があります。
- 公開ポータル
- 認証された学生ポータル
- 認証された教師用ポータル
- 認証された管理者ポータル
各ポータルが 100 の異なるビューで終わるとしましょう (野心的にしましょう!)。その規模が実現されれば、MVC エリアは、各エリア内で MvcCodeRouting を使用して、コードを分割するための優れた方法のように思えます。または、好きなようにコードを整理して、MvcCodeRouting に面倒な作業を任せる必要があるかもしれません。
したがって、エリアと MvcCodeRouting のデザインは次のようになります (フォルダー構造)。
- MvcWebProject
- エリア
- 管理者
- コントローラー
- モデル
- ビュー
- 公衆
- コントローラー
- モデル
- ビュー
- 学生
- コントローラー
- モデル
- ビュー
- 先生
- コントローラー
- モデル
- ビュー
- 管理者
- コンテンツ
- コントローラー
- スクリプト
- ビュー
- エリア
Areas のない MvcCodeRouting デザインは、次のようになります (フォルダー構造)。
- MvcWebProject
- コンテンツ
- コントローラー
- 管理者
- 公衆
- 学生
- 先生
- モデル
- 管理者
- 公衆
- 学生
- 先生
- スクリプト
- ビュー
- 管理者
- 公衆
- 学生
- 先生
これらの設計では、名前空間を介してクラスをさらに整理するために MvcCodeRouting が使用されることが暗黙的に示されています。
これらのあまりにも多くのデザインのうち、より良いアプローチはどれですか? なんで？さらに優れた別のアプローチはありますか？ポータル間でリソースを共有することは、設計によって簡単ですか、それとも難しいですか?
これは、コードのソリューション全体のフロントエンドにすぎないことに注意してください。したがって、この背後にあるサービス/ドメイン/データベース全体には、独自の特定のアーキテクチャがあります。この質問の目的のために、MVC でこれらのさまざまなアプリケーション領域をどのように設計する必要があるかに興味があります。