WCFサービスを構築しています。
データコントラクトオブジェクトは、ビジネスオブジェクトとまったく同じになります。
WCFサービスでデータコントラクトを作成するか、BOレイヤーを参照して、それらのビジネスオブジェクトをWCF操作で使用する必要がありますか?
WCFサービスを構築しています。
データコントラクトオブジェクトは、ビジネスオブジェクトとまったく同じになります。
WCFサービスでデータコントラクトを作成するか、BOレイヤーを参照して、それらのビジネスオブジェクトをWCF操作で使用する必要がありますか?
私はそれらを異なるプロジェクトに分割します:
サービスでBusinessModelsとDataContractsを参照します。次に、 AutoMapperを使用してモデルクラスをコントラクトクラスにマップし、その逆も同様です。WCFクライアントはコントラクトに依存しているため、後でモデルを変更しても、WCFクライアントを壊すことはありません。
シリアル化の懸念をビジネスロジックと混同することなくビジネスオブジェクトをシリアル化できるのであれば、それを試してみてください。
ただし、より良い代替策は、ビジネスロジックレイヤーをサービスレイヤーの背後に配置し、ビューがバインドできるサービスから単純なDTOを公開することです。
このアプローチに関する記事をWCFRIAサービスで作成しました。これは、標準のWCFWebサービスに非常によく変換されます。
これまでAutoMapperを使用したことはありませんが、@valpolushkinの同じ行にあると思います。
データコントラクトとしてビジネスエンティティを使用すると重大な変更が発生する可能性がある例については、 WCFメッセージとデータコントラクト、DTO、ドメインモデル、および共有アセンブリの私の回答を参照してください。
BusinessObjectsをDataContractsとして使用することは非常に悪い習慣だと思います。サービスは自律的である必要があります。このサービスは、LaxVersioningを持っている/持っていないクライアントによって使用される可能性があります。
サービスのバージョン管理を参照してください。
新しいメンバーを追加しても既存のクライアントが壊れることはないと誤解されがちです。すべてのクライアントが緩いバージョン管理を処理できるかどうかわからない場合は、厳密なバージョン管理ガイドラインを使用し、データコントラクトを不変として扱うことをお勧めします。
また、MSDN-サービスレイヤーガイドラインを参照してください
ビジネスエンティティとデータコントラクトの間で変換する変換オブジェクトを設計します。