10

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

XML WS現在、モデルへの移行を検討しWCF/object-basedており、さまざまなアプローチを試しています。そのうちの 1 つは、ドメイン オブジェクト/集合体をワイヤ経由で直接転送し、それらの DataContract 属性を呼び出す可能性があります。

で Order プロパティを使用するIExtensibleDataObjectことにより、単純なプロパティのバージョン管理の問題に対処できるはずです (すべてのクライアントを制御し、簡単に強制更新できることを思い出してください)。DataContractDataMembers

DTOs専用の転送専用のデータ転送オブジェクト ( ) をネットワーク経由で使用する必要があるとよく耳にします。

なんで？それでもそうする理由はありますか？サーバー側とクライアント側で同じドメイン モデルを使用します。もちろん、コレクションの事前入力などは、正しく「必要」と判断された場合にのみ行います。コレクション プロパティは、サービス ロケーターの原則と IoC を利用してNHibernate-based、(サーバー側で) データを直接フェッチする"サービス" と、サーバー ファームWCFと対話するクライアント側の "サービス" クライアントのいずれかを呼び出します。WCF

では、なぜ を使用する必要があるのDTOsでしょうか。

4

2 に答える 2

7

両方のアプローチ（共有ドメインオブジェクトとDTO）を使用したことで、共有ドメインオブジェクトの大きな問題は、すべてのクライアントを制御できない場合だと思いますが、私の過去の経験から、開発速度が本質。

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

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

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

于 2008-09-01T22:44:24.800 に答える
6

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

  1. ネットワーク経由で送信されるものを厳密に定義し、その定義専用の型を持ちます。
  2. アプリケーションの残りの部分、クライアント、サーバーを将来の変更から分離します。
  3. .Net 以外のシステムとの相互運用性。DTO は確かに必須ではありませんが、「安全な」型の設計が容易になります。

あなたのシナリオでは、これらの設計機能はそれほど重要ではないかもしれません。厳密な DTO と共有ドメイン オブジェクトの両方で WCF を使用しましたが、どちらのシナリオでもうまく機能しました。ドメイン オブジェクトをネットワーク経由で送信したときに気付いた唯一のことは、必要以上に多くのデータを (そして予想外の方法で) 送信する傾向があることでした。これは、何よりも、WCF の経験が不足していることが原因である可能性があります。しかし、そのルートを選択する場合は、必ず注意する必要があります。

于 2008-08-26T17:48:12.530 に答える