MVCのビュー、コントローラ、モデルをグループ化する

Question

多分私は間違っていますが、真剣に私はMVCアプリケーションの現在の構造が気に入らず、大きなプロジェクトでは維持するのが難しいと思います。

ので、グループに関連するコントローラ、ビュー、モデルへの道は、一緒にそこにある私は、ギャラリーのモジュールを持っている場合、私はすべてを望むようにそれはコントローラ、ビュー、モデルがギャラリーフォルダの下にグループ化することです。

Answer 1

Areasあなたが探しているもののようなものです。これにより、コントローラ/ビュー/ etcをグループ化できます。私がその質問を誤解していない限り？

Answer 2

MVCの基本原理に反して、Model、View、Controllerの分離ではなく、モジュールを使用して90度に分割したいと考えています。

私はあなたが1つのGalleryControllerを持っていることを期待しているので、あなたはそれをモジュールに分割することからどのような利益が得られるのか完全にはわかりません。あなたが最も「エンティティ」を持っている可能性が高い場所は、それぞれのGalleryControllerアクションごとに1つ以上のビューがありますが、それはあなたが探している機能の種類を与える独自のフォルダです。

最後にモデルがあります。明らかに私はあなたのプロジェクトを知らないので、どのようにレイアウトされているのかわかりませんが、モデルは通常、1つのコントローラ（またはあなたの場合はモジュール）を使用するためには存在しません。たとえば、ユーザー、会社、車両などのモデルがあります。これらのモデルは自分のデータ構造を共有して表現しており、ユーザーがWebページを見ているのを見ることができるため、モジュールとは関係ありません。モジュール全体に分割することはできません。全体のポイントは、アプリケーション全体で共有されるからです。

実際には、ちょっと面倒なビューがありますが、コントローラに基づいてフォルダに分割されています。それはあなたのニーズに合っている場合は、少し周りに移動することができると言っている。それ以外の場合は、「適切な」MVC（つまりモジュラーモデル）を使用したい場合や、必要がない（つまりコントローラが1つだけの場合）必要はありません。また、コントローラが大きすぎる場合は、分割したい機能のモジュールを個別に作成するだけです。私はあなたが得る必要があるようにモジュラーであると思います。

Answer 3

Phil Haack discussed this hereこれは、私が直面してきた問題であり、まだ正しく克服していない問題です。

Answer 4

IIS構成を使用して領域をシミュレートする比較的単純なソリューションが見つかりました。既存のMVCフレームワークへの拡張は必要ありません。

サイト内で必要な領域（ルート、ブログ、フォーラム、App1、App2など）ごとにソリューションの下に新しいMVCプロジェクトを作成します。共通のサポートコードまたは共通のモデルが必要な場合は、MVCプロジェクトが依存する個別のdllプロジェクトに配置します。

IISでは、サイトルートをルートプロジェクトディレクトリを指すように構成します。各サブエリアのプロジェクトディレクトリを指すサイトルートの下にWebアプリケーションを作成します。

各サブエリアのルートマップを設定する場合は、ルートにアプリケーションの名前を含めないでください。 IISはあなたのためにこれを世話しているようです。

利点は、ルーティングシステムとは独立したWebアプリケーションの名前を変更することができるということです。それぞれのアプリケーションでは、（「ShowPost/{postname}」は「/ Blog/ShowPost/{postname}それはサーバー全体で実行されています。