私は現在、あまりモジュール化されていない既存のASP.NETMVC3.0アプリケーションのアーキテクチャを再構築する方法を考えています。既存のプロジェクトを拡張可能にするために、構造のようなプラグインを念頭に置いています。
モジュラーWebアプリケーションを作成するためのさまざまな戦略を検索し、次のことを見つけました。これらのアイデアについてコメントしていただきたいと思います。
- 別のプロジェクトのMVCエリア
プラグインごとに、プラグインのコントローラー、ビュー、およびビューモデルを含む個別のASP.NETMVCプロジェクトを作成します。「従業員」モジュールには、従業員を一覧表示、作成、更新、および削除するための領域が含まれます。ただし、これは良さそうです。すべての領域を「bin」ディレクトリに配置するには、AreaRegistrationが必要です。AreaプロジェクトをAreasフォルダーに直接配置し、「/ Areas / [AreaName]/bin」フォルダーからAreaアセンブリを解決する方法を見つけました。
BuildManager.AddReferencedAssembly.Add(Assembly.LoadFrom(…));
AppDomain.CurrentDomain.AssemblyResolve += ResolveAssemblies;
これは非常にうまく機能しており、メインプロジェクトのAreasフォルダーにプラグインをデプロイできます。ASP.NETMVCによってすぐに提供されるエリア機能を使用しているのが好きです。
- MVCポータブルエリア（MVCContrib）
http://elegantcode.com/2012/04/06/mvc-portable-areas/
ポータブルエリアは、ビューがエリアプロジェクトファイルに埋め込まれたリソースとしてコンパイルされる必要があるため、適切なアプローチではないようです。これにより、IISのキャッシュが妨げられます。一方で、パフォーマンスの欠点が実際にどれほど大きいかは想像できません。
- MEFを使用したMVCベースのモジュール
http://www.fidelitydesign.net/?p=104
他のプロジェクトで疎結合サービスを作成するために、私はMEFに大きく依存しています。したがって、ASP.NETMVCモジュール/プラグインを検出するためにそれを使用するのは素晴らしいアイデアだと思いました。'Export'属性を使用してエクスポートされたコントローラーをインスタンス化するControllerFactoryを使用することになります。このようにして、プラグインのインスタンス化を完全に制御し、MEFを使用してサービスを取得できます。ただし、MEFを使用するには、コントローラーをすぐに解決するMVCエリアを使用するよりもはるかに多くの作業が必要になります。
- プラグインプロジェクト全体のエンティティフレームワーク
これまで解決できなかった問題の1つは、個々のプラグインプロジェクトにエンティティをどのように分散させるかです。現在、すべてのエンティティを含む1つの*.edmxモデルファイルで構成されるデータベースファーストアプローチを使用しています。DbContextまたはCodeFirstを使用しても、1つのデータベースに複数のDbContextクラスを使用することはできません。1つのアイデアは、MEFを使用して、さまざまなプラグインから中央のDbContextクラスにエンティティをロードすることです。ただし、これがサポートされているセットアップであるか、推奨されるセットアップであるかはわかりません。