ASP.NET MVC ソリューションを論理的に定義するにはどうすればよいですか? ソリューションをいくつのプロジェクトに分割する必要がありますか? これに対する標準的なアプローチはありますか?たとえば、モデル クラス ライブラリ、MVC Web アプリケーション (コントローラーとビューで構成される)、単体テスト プロジェクト、リポジトリ プロジェクトなどです。考えられるさまざまな種類のプロジェクトは何ですか?
2 に答える
答えは本当に依存します。プロジェクトの規模によって異なります。すべてを 1 つのプロジェクト (メイン MVC のプロジェクト) に含めることができ、さらに分割することもできます。このプロジェクトの正規形は次のようなものです。
project.WEB
project.Common (here belongs common functionality between projects, so helpers, utilities, even some extension methods belong there)
project.Model (Data entities)
project.BL //(Business Logic)
project.DAL //(Data Access Layer or Persistence)
project.Tests
*「プロジェクト」は名前空間のルートであることに注意してください。名前空間の命名を処理する方法は、そこで確認できます:名前空間の命名規則
そして、あなたはそれをさらに分割することができます。ただし、これ以上分割して誇張しないことをお勧めします。あなたがそれをしなければならないとき、あなたは知っているでしょう(1つのプロジェクトが大きくなりすぎて、ロジックの分離があります...)。YAGNIの原則に従おうとします。
後もう一つ。「本で」そこに行きたい場合は、DDD - Domain Driven Desing: http://msdn.microsoft.com/en-us/magazine/dd419654.aspxをチェックしてください。
これは非常に幅広い質問ですが、以前のプロジェクトで行ったことの例を挙げます。まず、アプリケーション全体の複雑さと、開発者の個人的な好みによって異なります。単純なアプリは、1 つの MVC 4 アプリケーション内にうまく収まります。
Web Project - for the views using MVC4
Application - for business logic)
Data - for repositories and webservice methods)
Domain - for the objects used in the app
Utilities - for common functionality that needs to be used in more than one project
上記の例は、プロジェクトに非常にうまく適合しているため、すべての懸念事項を分離して、プロジェクトをより保守しやすくすることができました。