WCFサービスとEntity Frameworkのnティアアプリケーションの問題

Question

より大きいシステムの一部であるWCFサービスを開発中です。サービスはビジネスロジックを提供し、Entity Framework（モデルファーストを使用）を介してデータベースに接続されます。 Entity FrameworkをWCFサービス（基本エンティティ、DTO、自己追跡エンティティ、POCOなど）と連携させる方法はさまざまです。私の基本的な要件：

• サービスは、シンクライアント（および他のサービス）のために構築され、ロジックのほとんどは、その側にあるので、それは任意のCRUDアプリではありません（WCF Data Servicesのは私のためではありません）
• データベース内の同じエンティティのための私の要求にそれが構築されるべきか、私のビジョンは、（私はそれが一番近いと思うに最も近い別のデータコントラクト

が存在しますので、異なるクライアントは、粒度の異なるレベルでデータを必要としますDTOアプローチへ）： http://www.codeproject.com/Articles/127395/Implementing-a-WCF-Service-with-Entity-Framework

しかし、私は、データアクセス層はサービスのロジック（2つのアセンブリ：プロジェクト、名前空間、dll、しかし1つのアプリケーションとして動作する）から分離されるべきだと思います。この場合、私はいくつかの問題があります。これらの2つの層のそれぞれは何をすべきですか？サービス内ですべてのロジックを実行し、DALをCRUDと同じように使用する必要がありますか？または、データベース全体のロジック（linqを使用した特定のクエリ）はDAL（DALによって公開されるより多くの特定のメソッド）で実行されますが、サービスは明確なビジネスロジックのみを担当する必要がありますか？また、データコントラクト、エンティティ、または追加モデルの2つのレイヤーの間で、どのオブジェクトを送信すべきか重要なのは何ですか？

上記の状況で私のアプローチはOKですか？

Answer 1

SOAの前には、通常、N層または3層アーキテクチャに専用のビジネス層がありました。懸念が十分に解消されていると感じている場合（またはサービスを利用していない消費者からビジネス機能を再利用することが考えられる場合）、ビジネスロジックをサービス層から外してみませんか？ （ビジネスロジックをDALに入れないでください）

しかし、サービス層がトランザクションと同様にデータクエリサービスを提供する場合、ビジネスレイヤはこれらのサービスには必要ありません.CQRSタイプのデザインパターンはここにあります。

エンティティ（名前、xmlnsなど）のXML形式を制御する必要がある場合は、おそらくカスタムWCF DataContractまたはMessageContractエンティティを作成する必要があります。 しかし、ワイヤを介してデータがどのように見えるか気にしない場合は、単にEFエンティティクラスを使用することができます（Contextにバインドされていない限り、つまりEFでPOCOを使用する場合）。 DataContractなどでPOCOを属性しない場合、DataContractSerializerの既定の動作はパブリックプロパティをシリアル化することです。

ですから、以下のアセンブリ '層'（ボトムアップ）EF用

• DALエンティティ（バインドされたObjectContextまたはPOCOのいずれか）
• EF DAL
• トランザクションのためのビジネス・レイヤー（と羽目になる可能性があり
• POCO/DAL BEをDataContract/MessageContractにマップする可能性のある別個のWCFエンティティ
• WCFサービスレイヤ