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

Question

典型的なシナリオ。サーバーファームと複数の分散およびローカルクライアントとの通信には、旧式のXML Webサービス 内部的に を使用します。サードパーティは関与せず、自分自身と顧客が使用するアプリケーションのみ。

現在、 XML WS モデルから WCF /オブジェクトベースモデルへの移行を検討しており、さまざまなアプローチを試しています。そのうちの1つは、ドメインオブジェクト/集計をワイヤ経由で直接転送し、場合によってはそれらのDataContract属性を呼び出すことです。

IExtensibleDataObject および DataMembers のOrderプロパティを使用する DataContract を使用することで、単純なプロパティバージョン管理の問題に対処できるはずです（すべてのクライアントを制御し、それらを簡単に強制更新できることを忘れないでください。

専用の転送専用データ転送オブジェクト（ DTO ）をネットワーク経由で使用する必要があると聞き続けています。

なぜですか？そうする理由はまだありますか？サーバー側とクライアント側で同じドメインモデルを使用します。もちろん、適切で「必要」と見なされた場合にのみ、コレクションの事前入力などを行います。コレクションプロパティは、サービスロケーターの原則とIoCを利用して、 NHibernateベース＆quot; service＆quot;を呼び出します。 （サーバー側で）データを直接取得するため、および WCF ＆quot; service＆quot; WCF サーバーファームと通信するクライアント側のクライアント。

では-なぜ DTO を使用する必要があるのですか？

Answer 1

私の経験では、DTOは次の用途に最も役立ちます。

1. ネットワークを介して送信されるものを厳密に定義し、その定義に特化したタイプを持つ。
2. アプリケーション、クライアント、サーバーの残りを将来の変更から分離します。
3. 非.Netシステムとの相互運用性。 DTOは確かに要件ではありませんが、「安全」な設計を容易にします。タイプ。

シナリオでは、これらの設計機能はそれほど重要ではありません。厳密なDTOと共有ドメインオブジェクトの両方でWCFを使用しましたが、両方のシナリオでうまく機能しました。回線を介してドメインオブジェクトを送信するときに気付いた唯一のことは、必要以上に多くのデータを（予期しない方法で）送信する傾向があったことです。これは、他の何よりもWCFの経験が不足しているためと思われます。しかし、あなたがその道を行くことを選択した場合、それはあなたが間違いなく警戒すべきものです。

Answer 2

両方のアプローチ（共有ドメインオブジェクトとDTO）で機能したこと共有ドメインオブジェクトの大きな問題は、すべてのクライアントを制御できないことです。スピードが重要でした。

クライアントを常に制御できない可能性がある場合は、DTOをお勧めします。ドメインオブジェクトを他の誰かのクライアントアプリケーションと共有するとすぐに、内部を他の誰かの開発者に結びつけるからです。サイクル。

また、バージョン化されたサービス環境で作業するときにDTOが役立つことがわかりました。これにより、アプリの内部を根本的に変更できますが、古いバージョンのサービスインターフェイスへの呼び出しを受け入れることができます。

最後に、クライアントアプリケーションが多数ある場合は、DTOを使用すると有益な場合があります。これは、簡単にバージョン管理可能なサービスで保護されるためです。