DTO オブジェクト (データ転送オブジェクト) を効果的に使用するにはどうすればよいですか?

StackOverflow https://stackoverflow.com/questions/512880

質問

DTO を実装する最良の方法は何ですか?

私の理解では、これらはオブジェクト間でデータを転送する 1 つの方法であると考えています。たとえば、ASP.Net アプリでは、DTO を使用してコードビハインドからビジネス ロジック レイヤー コンポーネントにデータを送信できます。

データをメソッドパラメータとして送信するだけなど、他のオプションについてはどうですか?(送信するデータが少ない asces ではこれが最も簡単でしょうか?)

データを保持するだけで、他のオブジェクトから参照できる静的クラス (一種のグローバル アセンブリ データ ストレージ クラス) はどうなるでしょうか?(これはカプセル化を壊しすぎますか?)

すべての転送に単一の汎用 DTO を使用する場合はどうなるでしょうか?使用するのは少し面倒かもしれませんが、操作に必要なクラスの数が減ります (オブジェクトの乱雑さが軽減されます)。

ご意見をお聞かせいただきありがとうございます。

役に立ちましたか？

解決 6

すべての役に立つアイデアをありがとう...

この上の要約+私のテイクます：

- それを動かすためにあまりにも多くの場所を移動しないように少量のデータがある場合は、通常のパラメータは十分である。

- それは、特別に作成されたオブジェクトは、最も簡単な（DTOオブジェクト）とすることができるに移動するデータおよび/または多くのオブジェクトがたくさんある場合

- さまざまなオブジェクトによって（渡されたのではなく）参照できるグローバルデータオブジェクトは、時々、特定のサブシステム内のそれのための場所がない場合しかし、私は疑問に思う...に眉をひそめているように見えるだろう？これは、データの受け渡しの量を減らすための一つの方法です。それはおそらく、それはクラスのparticluar assemplyにシンプルさを追加することができ、しかし、特定の層内の特定のインスタンスでは、「良いカプセル化」の限界を押し広げるん。したがって、一つはクラスレベルのカプセル化を失うことになるが、それでもアセンブリレベルのカプセル化を持つことができます。

他のヒント

私は DTO を次の目的で使用しました。

  • 標準の 3 層アプリの UI とサービス層の間でデータを渡します。
  • データをメソッド パラメーターとして渡し、多数 (5 以上) のパラメーターをカプセル化します。

「1 つの DTO ですべてを支配する」というアプローチは面倒になる可能性があります。最善の策は、機能/機能グループごとに特定の DTO を使用し、使用されている機能間で簡単に一致できるように名前を付けることに注意することです。

私はあなたが言及した方法で静的 DTO を見たことがなく、あなたが説明したような DTO シングルトンを作成することを躊躇します。

私はそれをシンプルに保つと、1デシベルのテーブルに1つのDTOクラスをマップします。彼らは、軽量であるので、私は、ワイヤ上を含め、どこにでもそれらを送信することができます。

私はそれはのように単純なものなあ。 DTOがあるため、システムのネットワーク配信階層に由来するものの、ドメインオブジェクトがレイヤーを表示するために返された場合は問題の全体ロードすることができます。ここではそのうちのいくつかをされます：

レイヤーを表示するためにドメインオブジェクトをさらす1.By、ビュービューをすることができますドメインオブジェクトの構造の自覚が用意されていますどのように関連するオブジェクトに関するいくつかの仮定をします。たとえば、ドメインオブジェクト「人」がビューにretunrnedれた場合、それは「バウンド」といくつかの他のビューの上にあると、「アドレス」、人のようなセマンティックを使用するには、アプリケーション層のための傾向があるだろう、バインドしますその時点でアドレスのドメインオブジェクトがポイントでロードされていない可能性があるため失敗woukd person.getAddresse（）。本質的には、ドメインオブジェクトは、レイヤーを表示するには利用できるようになって、ビューは常にデータが利用できるようになる方法についての仮定を行うことができます。

ドメインオブジェクトはビュー（シック・クライアントでとても以上）にバインドされている場合、

2。）、alwyasビュー中心の論理はそれらを論理的に破損して作り、これらのオブジェクトの内側にクリープする傾向があるでしょう。

基本的に私の経験から、私はビューへのドメインオブジェクトを利用可能にするアーキテクチャ上の問題を作成することを見てきましたが、DTOの使用はアセンブラの創造という点で追加作業を作成しますので、DTOの使用に問題もある（DTOドメインオブジェクトへと逆）患者ドメインオブジェクト、患者DTO及び表示するために結合し、おそらく患者ビーンなどの類似オブジェクトの増殖

明らかに特別に厚いクライアントシステムでは、このための正しい答えはありません。


：

私はからDTOの決まり文句にこの短いと完全ではありませんが、真の答えを借り http://www.theserverside.com/discussions/thread.tss？ thread_idは= 32389＃160505 の

私はそれが「それらすべてを支配する1 DTO」としてのDataSet / DataTableのを使用するのはかなり一般的だと思います。これは、データベースからそれらをロードし、バックの値を保持するのは簡単だし、彼らは簡単にシリアライズすることができます。

私は間違いなく、彼らが使用するために多くの問題であると言うでしょう。彼らは、配管のすべてを提供しませんが、それらに対するプログラミングは、痛み（鋳物の多くは、nullチェックし、魔法の文字列など）です。もう少し「自然な」彼らと一緒に作業を行うために拡張メソッドの良いセットを見るのは興味深いだろう。

のDTOはないオブジェクト間、ワイヤを介してデータを送信するために使用されます。この記事をチェックアウト： DTO の対 POCO

所属していません StackOverflow
scroll top