アーティファクトタイプ（コントローラ、ビュー）ごとに1つのフォルダではなく、機能ごとに1つのフォルダ（Customers、Orders）を使用してWebアプリケーションを構造化する方法を知りたいと思います。これは、多くの機能を備えた大規模なプロジェクトを編成するよりはるかに良い方法だと思われますが、私はそれに関する情報を見つけることができません。アーティファクトごとではなく、機能単位ごとの組織を使用してASP.NET MVCアプリケーションを構造化する方法は？
エリアごとに1つのエリアを使用すると、多くのネストされたフォルダを作成する必要があるため、エリアを使用すると解決策にはならないと思います。
私は、IViewEngineの実装をカスタマイズすることで、私がしたいことが可能になるはずですが、それについてはわかりません。
誰でもこれを試みましたか？
必要に応じて、ビューの保存場所を変更することができます。例：http://weblogs.asp.net/imranbaloch/archive/2011/06/27/view-engine-with-dynamic-view-location.asp。
ASP.NET MVCは、構成上の慣習の哲学のために開発が容易です。あなたが本当にそれらの慣習を変えたいなら、あなたはできます。しかし、より多くのコーディングを行うことができます。たとえば、スキャフォールディングはあなたの設定では動作しません。
アーティファクトフォルダ内に論理区切りを作成するだけではどうですか。したがって、Modelsフォルダ内にViewModel用のフォルダとDataModel用のフォルダがあります。 DataModelsフォルダ内で、モデルの異なるサブセット（顧客、注文など）用のフォルダを作成します。ちょうど私の2セント。
ルートフィーチャーフォルダーを作成し、フィーチャーごとに1つのフォルダーを作成し、フォルダー内に共有フォルダーを作成することができます。次に、単一の機能に関連するすべてのファイル（コントローラ、モデル、ビュー、スクリプト）をそのフォルダに追加できます。複数の機能が同じファイルを使用している場合は、共有フォルダに追加できます。あなたは適切なViewLocationFormatsを設定RazorViewEngineから継承された新しいビューエンジンクラスを作成する必要があり、このフォルダ構造、MasterLocationFormats、PartialViewLocationFormatsでカミソリを使用して、ビューのインスタンスを追加するために
：これは、プロジェクトの構造がどのように見えるかもしれ方法ですエンジンをViewEngines.Enginesコレクションに追加しました。サンプル実装では、Tim G. Thomasの使用チェックFEATURE FOLDERS IN ASP.NET MVC articleです。
ビューでScriptsのようなクラスを使用する場合は、名前空間もインポートする必要があります。これを行う1つの方法は、古いViewsフォルダのWeb.configファイルをFeaturesフォルダにコピーすることです。別のオプションについては、How do I import a namespace in Razor View Page?の質問を確認してください。
これは多かれ少なかれ私が元のco natives：http://www.paulstovell.com/horizontal-vertical-project-structure - 私はすでに他のプロジェクトでこの種の構造を使っています。それは私によく合います。 これは、IViewEngineとIControllerFactoryの実装をカスタマイズすることができることを知っています。ここでは、この慣習の変更についての実践的な経験と、それが価値あるものではない理由があります。 注：スキャフォールディングは使用しません – gschuager
私は同意します。役割別にグループ化するコントローラー/モデル/ビューは、プロジェクトがいくつかのコントローラーを超えて成長すると、本当にあなたを噛み始めます。フィーチャベースの組織は、プロダクションプロジェクトの編成において非常に先進的です。どのプロジェクトでもそれを強く推奨します。 – demisx