私はこのデザイン コンセプト全体に不慣れで、ここ数週間の読書で多くの情報を集めましたが、散らばっていて矛盾しているように見えます。条件はまちまちで、私はこれを理解するのに苦労しています。
私が使用しているパターンは次のようなもので、次のような流れを想定しています。
MVC アプリケーション
コントローラーは、特定のビューに対するクライアントからの要求/応答を処理します。コントローラーのアクション メソッド内で、サービス (サービス レイヤー) に接続し、オブジェクトを要求してビュー モデルを構築し、ビュー モデルからオブジェクトを送り返します。
ビュー モデル ビュー
との間で強く型付けされたビュー モデルを使用しています。
ビュー モデルは DTO ですか? Name、AddressLine1、Address City などの単純なプロパティだけを含めるか、複雑なプロパティや複数のオブジェクトなどを含める必要があります。
ビューモデルでの検証です。もしそうなら、それは必須フィールド、フィールド長などの検証になりますか?ユーザー名などの検証は既に存在しますか、それともサービス層の他のオブジェクトと対話する必要がある場所ですか?
ビュー モデルに EF から返された POCO クラスのみを含めることはできますか?それとも AutoMapper を使用する必要がありますか?
AutoMapper と DTO を使用している場合、DTO のクローンは POCO クラスですか?
コントローラー、ビュー モデル、または下のサービス レイヤーにマップしますか?
サービス
私にとって、サービスとは、EF から POCO オブジェクトを取得するためにリポジトリに接続するオブジェクトです。これは、すべてのビジネス ロジックが存在する場所です。サービスがオブジェクトをリポジトリに戻して EF に永続化すると、それらは有効なオブジェクトと見なされます。これは正しいです？
リポジトリ
それらにはビジネス ロジックはありません。サービスと EF の間でオブジェクトを転送するためにのみ使用されます。これは正しいです？ここでは、汎用リポジトリを使用してインターフェイスを実装しています。次に、特別なニーズに合わせて汎用リポジトリを拡張できますか?
用語に関する質問
1) ビジネス オブジェクトはドメイン オブジェクトと同じですか。ドメイン オブジェクトにはどのくらいのロジックを含める必要がありますか?
2) ドメイン モデルは EF モデルですか? モデルファーストのアプローチを使用しています。
3) 依存性注入 - これを使用する必要がありますか? 私はそれがどのように機能するかを理解していますが、本当の利益を得られません. 私はNinjectで遊んでいました。
コミュニティは、コード サンプルを含むすべてのベスト プラクティスを含むある種の wiki から恩恵を受けると思います。そこにそのようなものはありますか？出回っているサンプルの多くは非常に単純であり、Microsoft のサンプルの多くは、主張している場合でもこのパターンを使用していません。
これを手伝ってくれるすべての人に前もって感謝します。
ところで-StackOverflowには、「Accept Answer」チェックボックスの横にある「Buy Me A Beer」ボタンが少し必要だと思います:)