MVC4 を使用してオンライン製品を構築しています。
現在、私はプロジェクトを明白な xx.Web、xx.Data、xx.Services に構造化しました。
以下は、あなたの意見を聞きたい一連の質問です。
1- データ層には、リポジトリ パターンを使用します。データベース テーブルをホストする .dbml を作成しました。テーブルごとにクラスを作成する必要がありますか、それとも .dbml によって生成されたクラスを使用する必要がありますか? 2- どこ リポジトリ インターフェイスの場合、どこに配置すればよいですか? 別のプロジェクト xx.Data.Common または xx.Data 内のフォルダーに?
3- エラー ログとセキュリティ コードはどこに行くのですか? そのために xx.Web.Common プロジェクトを作成しましたか?
MVC アプリケーションの共通アーキテクチャに関するガイドラインはありますか? つまり、私はいくつかの調査を行いましたが、Ninject などの拡張機能のトーンであふれています...
ベストプラクティスを実装したいだけです。ありがとう
すぐに使えるベスト プラクティスの開始テンプレートについては、 http://sharparchitecture.net/があります。しかし、私がオンラインで見かけるソリューションのほとんどは、過剰に設計されており、エンタープライズ レベルのサイトを対象としていると思います。
オンライン製品を作成するだけの場合 は、2 ～ 3 層のシンプルなソリューションで十分です。可能な限り簡単な解決策から始めてください。必要に応じて、いつでも追加したり、新しいレイヤーを作成したりできます。
1- データ層には、リポジトリ パターンを使用します。データベース テーブルをホストする .dbml を作成しました。テーブルごとにクラスを作成する必要がありますか、それとも .dbml によって生成されたクラスを使用する必要がありますか?
Web を最初から構築する場合は、Linq2Sql が進化していないため、Entity Framework で Code First を使用することをお勧めします。
モデルからデータベース テーブルに 1 : 1 でマップする必要はありません。まずドメイン モデルの設計に集中してください。データベースは自動的に生成されます。また、テーブルを使用してリポジトリから 1 : 1 にマップする必要はありません。Aggregate および Aggregate Root を使用したリポジトリ パターンを理解する必要があります。
2- どこ リポジトリ インターフェイスの場合、どこに配置すればよいですか? 別のプロジェクト xx.Data.Common または xx.Data 内のフォルダーに?
ドメイン モデルとリポジトリ インターフェイスを配置するために、xx.Domain という名前の dll がもう 1 つ必要です。このように、xx.Domain は他のアセンブリに依存しないコア アセンブリです。
3- エラー ログとセキュリティ コードはどこに行くのですか? そのために xx.Web.Common プロジェクトを作成しましたか?
ログとセキュリティのために、xxx.CrossCuttings という名前の dll がさらに必要です。
IoC コンテナーを使用して、レイヤー間の疎結合とテスト容易性を実現します。
MVC アーキテクチャの一般的なガイドラインではありませんが、コードをシンプルに保ち、保守しやすく、柔軟にすることが重要です。