WCF N-Tierアーキテクチャ

Question

私は非常に単純な多層アプリケーション（WPF、WCF、EF 4、SQL）に取り組んでいます。アーキテクチャに関しては、エンティティとサービス契約の両方を含む単一の「共通」プロジェクトを含める予定です。

エンティティとサービス契約を別々のアセンブリに持たせることには利点と欠点はありますか？それとも、それらを一緒に保つのが大丈夫ですか？

私は他人の意見を聞くことに興味があります。

ありがとうございます！

Answer 1

別々のアセンブリで契約を結ぶと、Contractsアセンブリを開発者に提供することによって、異なるアセンブリの異なるエンティティに注入することができ、実装して内部に配置できるdllを提供できるという利点がありますプロジェクトフォルダとは、私がどのように構造化さ

Answer 2

が正確であること...、

エンティティが実装に契約を結ぶ含まれている同じアセンブリ内の契約を持つ再構築することなくのStructureMapのようなのIoCフレームワークを使用して、それに注入します私が設計した電子商取引のn層アプリケーションの設計。

一般的なライブラリには、DTO用ライブラリとインタフェース用ライブラリの2つがあります。

次に、クライアントとサーバーにこれらのライブラリが含まれ、サービスプロキシが共通タイプを使用して生成されました。

ここでの主な利点は、コンパイルが容易なことです。インスツルメントを変更するときにプロキシを再作成する必要はなく、クライアントとサーバーは自動的に更新されます。

私は必要なすべてのヘルパータイプのものが含まれているユーティリティアプリもありました。

編集：申し訳ありません、あなたの質問をもう一度お読みください。私の場合は、ワークフローライブラリ（構成済みインターフェイスあり）とサービス（ワークフロー操作に構成されているもの）用に複数のインターフェイスライブラリがありました。

私の場合は別にしておくことが理にかなっていました。

インターフェイスが1セットしかなく、これらのインターフェイスがすべてDTOを使用している場合、2つのライブラリに分離する理由はありません。将来的にはより多くのインタフェースライブラリの間でDTOを共有する必要があるかもしれない場合は考慮してください。その場合は、DTOを最初からインタフェースから分離してください。

Answer 3

他の.NETプラットフォームのコンシューマでRESTfulアーキテクチャを使用している場合 - 不要なものを公開することなく、RESTfulコンシューマと操作およびデータ契約を簡単に共有できるように、サービス契約を別のアセンブリ（共有）にすると便利です。データアクセスコンポーネントをクライアントに提供します。

この理由から、データアクセスとサービス契約を分離しておくことをお勧めします。