MVC3アプリケーション/サービスレイヤ/リポジトリレイヤ/ POCOクラス/ EF4 - 質問！

Question

私はこのデザインコンセプト全体を初めて勉強しています。ここ数週間、私は多くの情報を集めましたが、散らばって矛盾しているようです。用語は混在していて、私はちょうどこれを念頭に置いて苦労しています。

私が使用していたパターンは次のようであり、以下のように流量を想定：

MVCアプリケーション
コントローラ（単数または複数）は、所与のビューのクライアントからの要求/応答を処理します。コントローラのアクションメソッドの中で、それらはサービス（サービスレイヤ）に連絡し、オブジェクトを要求してビューモデルを構築し、オブジェクトをビューモデルから元に戻します。

ビューモデル
私はビューに強く型付けされたビューモデルを使用しています。

ビューモデルはDTOですか？ Name、AddressLine1、Address Cityなどの単純なプロパティを含むか、複雑なプロパティ、複数のオブジェクトなどが含まれている必要があります。

ビューモデルでの検証ですか。そうであれば、必須フィールドやフィールド長などの検証となります。ユーザー名のような検証はすでに存在していますか、サービスレイヤー内の他のオブジェクトと対話する必要があるのでしょうか？

ビューモデルにEFから返されたPOCOクラスのみが含まれているか、AutoMapperを使用する必要がありますか？

AutoMapperとDTOを使用している場合、DTOのPOCOクラスのクローンはありますか？

コントローラ、ビューモデル、または下のサービスレイヤにマッピングしますか？

サービス
私には、サービス（複数可）POCOバックEFからオブジェクトを取得するためのリポジトリ（複数可）に連絡するオブジェクトです。これは私のビジネスロジックのすべてです。サービスがオブジェクトをEFに永続化するリポジトリに戻すと、それらは有効なオブジェクトとみなされます。これは正しいです？

リポジトリはそれらには、ビジネスロジックはありません
、彼らは単にサービス（複数可）とEF間でオブジェクトを転送するために使用されています。これは正しいです？ここでは汎用リポジトリを使用してInterfacesを実装しています。次に、特別なニーズのためにジェネリックリポジトリを拡張することができますか？

質問
1）ビジネスオブジェクトはドメインオブジェクトと等しいですか？ドメインオブジェクトにはどのくらいの論理が含まれていますか？

2）ドメインモデルはEFモデルですか？私はModel-Firstアプローチを使用しています。

3）依存性注入 - これを使用すべきですか？私はそれがどのように機能するのか理解しています。本当の利益を得られません。私はNinjectで遊んでいた。

コミュニティには、コードサンプルを含むベストプラクティスを含むいくつかの種類のウィキが役立つと思います。そこにそんなことがありますか？多くのサンプルは非常にシンプルであり、多くのMicrosoftサンプルは主張していてもこのパターンを使用していません。

私はこれを持っていて、これで私を助けてくれるすべての人に事前に感謝します。ところで

- 私は「答えを受け入れる」チェックボックスの横にあるボタン「ミービールを買う」、StackOverflowのが少し必要だと思います:)

Answer 1

は、ビューモデルDTOのはありますか？

コントローラーとビューの間の一種のデータ転送オブジェクトと考えることができます。

、彼らはなど、市の住所、氏名、住所1のような単純なプロパティが含まれているか、彼らは複雑なプロパティが含まれている必要があります万一、複数のオブジェクトなど

理想的には単純なプロパティだけでなく、他のビューモデルを集約することができモデルはありません（例：EFモデルのように）。

検証はビューモデルで行われますか。

検証ロジックには、サービスバリデーション（ユーザー名は既に存在します）があり、サービスレイヤーに入り、ビューモデルに入るUI検証（例：ユーザー名が必要です）の2種類があります。

ビューモデルにはEFから返されたPOCOクラスのみが含まれていますか、またはAutoMapperを使用する必要がありますか？

ビューモデルのEFはありません。ビューモデルは、単純なプロパティと他のビューモデルを指す他の複雑なプロパティを持つPOCOクラスです。それらのモデルは、それらのモデルが意図した特定のビューで提示されるデータを適切にフォーマットするためのメソッドを含むこともできます。

AutoMapperとDTOを使用している場合、DTOのPOCOクラスのクローンはありますか？

私はこの質問をよく理解していません。

コントローラー、ビューモデル、または下のサービスレイヤーにマッピングしますか？

コントローラ。

私にとって、サービスは、EFからPOCOオブジェクトを取得するためにリポジトリに連絡するオブジェクトです。これは私のビジネスロジックのすべてです。サービスがオブジェクトをEFに永続化するリポジトリに戻すと、それらは有効なオブジェクトとみなされます。これは正しいです？

はい。

ドメインモデルはEFモデルですか？

EFコードを最初に使用している場合は、それ以外の場合は、いいえ（EFがEF固有の属性とクラスでドメインを汚染する場合）。

ビジネスロジックは存在せず、サービスとEFの間でオブジェクトを転送するために使用されます。これは正しいです？

はい。

ここでは、汎用リポジトリにインターフェイスを実装しています。次に、特別なニーズのためにジェネリックリポジトリを拡張することができますか？

はい、あまりにも気にならないです。通常、リポジトリはCRUD操作のためのものです。ビジネスロジックを含めるべきサービスです。

ドメインオブジェクトと等しいビジネスオブジェクトですか？

はい。

ドメインオブジェクトにはどのくらいの論理が含まれていますか？

これは、作業している特定のプロジェクトのドメインロジックの量と、あなたや他の誰かが作業していた古いプロジェクトから再利用できる既存のドメインロジックに依存します。

依存性注入 - これを使用する必要がありますか？

はい、絶対に。

私はそれがどのように動作するかを理解し、ちょうど真のメリット

それはターンでユニットテストにそれらを容易にし、その他に再利用し、アプリケーションの異なる層の間に弱い結合を提供し得ることはありませんプロジェクト。

コミュニティには、コードサンプルのすべてのベストプラクティスを含む何らかの種類のウィキが役立つと思います。

私は同意します。

そこには何かがありますか？

私はそれを疑います。

ところで - 私はStackOverflowのが少し必要だと思い、「回答を受け入れる」チェックボックスの隣に

のボタン「ミービールを購入することは、」詳細を同意することはできません。