WCF - ドメインオブジェクトとIExtensibleDataObject

Question

典型的なシナリオ。私たちは、サーバーファームと複数の分散とローカルクライアント間の通信のために内部古い学校のXML Webサービスを使用します。第三者は関与しません。当社とお客様が使用するアプリケーションのみ。

我々は現在、WCF /オブジェクトベースモデルにXMLのWSから移動熟考していると、様々なアプローチで実験されています。それらのうちの1つは、ドメインオブジェクト/集約をワイヤ上で直接転送し、おそらくそれらにDataContract属性を呼び出します。

DataMembersのOrderプロパティを使用してIExtensibleDataObjectとDataContractを使用することで、単純なプロパティのバージョニングの問題に対処できます（すべてのクライアントを制御し、簡単に強制的に更新できます）。

私たちは、ワイヤの上に専用の、転送専用のデータ転送オブジェクト（DTO）を使用する必要があることを聞いておきます。

なぜですか？そうする理由はまだありますか？私たちは、サーバー側とクライアント側で同じドメインモデルを使用します。もちろん、権利と "必要"とみなされる場合にのみ、コレクションを事前に埋め込みます。コレクションプロパティは、サービスロケータの原則とIoCを使用して、Hibernateベースの "サービス"（サーバー側）を直接フェッチするか、クライアント側のWCF "サービス"クライアントを呼び出してWCFサーバーファームと通信します。

だから、なぜDTOを使用する必要がありますか？私の経験のDTOで

Answer 1

はのために最も有用です：

1. は厳密にワイヤ上で送信されますどのような定義し、特にその定義に専念型を有します。
2. アプリケーション、クライアント、およびサーバーの残りの部分を将来の変更から隔離します。
3. 非Netシステムとの相互運用性。確かにDTOは要件ではありませんが、「安全な」タイプの設計が容易になります。あなたのシナリオでは

これらのデザインの特徴は、そのあまり重要ではないかもしれません。厳密なDTOと共有ドメインオブジェクトの両方でWCFを使用しましたが、どちらのシナリオでもうまくいきました。私が、ドメインオブジェクトを電信網を介して送信する際に気づいた唯一の事は、私が必要としていたより多くのデータを（そして予想外の方法で）送信する傾向があったことでした。これは、WCFの経験が他の何ものよりも少ないために起こりそうです。あなたがそのルートに行くことを選んだ場合、あなたが間違いなく慎重にすべきことです。

Answer 2

両方のアプローチ（共有ドメインオブジェクトとDTO）で作業していたのですが、共有ドメインオブジェクトの大きな問題は、すべてのクライアントを制御していないときですが、私の過去の経験からは、開発スピードは本質的でした。

あなたが常にクライアントをコントロールすることができない可能性がある場合は、DTOを必ずお勧めします。ドメインオブジェクトを他の誰かのクライアントアプリケーションと共有すると、 devサイクル。

私たちは根本我々のアプリの内部を変更するが、それでも私たちのサービス・インターフェースの旧バージョンへの呼び出しを受け付けることができ、バージョン管理サービス環境で作業しているとき、私はまたのDTOが有用であることが分かってきました。あなたは、クライアント・アプリケーションの多くを持っている場合

最後に、また、あなたが、簡単にバージョン管理サービスで保護されているとしてのDTOを使用することが有益であるかもしれません。