問題タブ [data-transfer-objects]

私が尊敬するメンターの 1 人は、単純な Bean は時間の無駄だと示唆しています。値オブジェクトには、有用なビジネス ロジックが含まれている必要があります。

また、そのようなコードは保守が難しく、すべてのビジネス ロジックを外部化する必要があると言う人もいます。

この質問は主観的であることを理解しています。とにかく尋ねる - より多くの視点からの答えを知りたい.

ドメイン駆動型設計の詳細があまりないように思われる部分の 1 つは、ドメイン モデルをインターフェイスから分離する方法と理由です。私はこれが良い習慣であることを同僚に納得させようとしていますが、あまり進歩していないようです...

彼らは、プレゼンテーション層とインターフェイス層の好きな場所でドメイン エンティティを使用します。表示モデルまたは DTO を使用してドメイン層をインターフェイス層から分離する必要があると彼らに主張すると、彼らはそのようなことを行うことにビジネス上の価値がないと反論します。元のドメイン オブジェクトと同様に。

そのため、これを裏付けるために使用できる具体的な理由を探しています。具体的には：

1. プレゼンテーション層でドメイン オブジェクトを使用してはいけないのはなぜですか?
   (答えが明らかな「デカップリング」である場合は、このコンテキストでこれが重要な理由を説明してください)
2. インターフェイスからドメイン オブジェクトを分離するために、追加のオブジェクトまたは構造体を使用する必要がありますか?

私の Windows フォーム アプリでは、マスターと詳細の関係を表す 2 つの DataGridView を使用しています。それぞれのデータソースは Data Transfer Object であり、IList(of T) として表されます。したがって、DataRelation はアウトです。マスター/ディテール グリッドを操作する最良の方法は何ですか? .NET でこれを行う組み込みの方法はありますか? または、選択したマスター行が変更されたときに独自の再バインドを作成する必要がありますか?

次の段落のAPIの意味を教えてください。実際にはTransfer Objectに関するものです。

ビジネス サービスが、そのデータのすべてまたはほとんどを大規模で大まかなメッセージで送受信するように求められる可能性が高い場合、そのサービスがAPIでその機能を提供するのは一般的です。

前もって感謝します。

最近、データ転送オブジェクト（DTO）はアンチパターンだと言う人を耳にしました。

なんで？選択肢は何ですか？

私はこのパターンを何度も見て、意見を求めたかった:

オプション 1: ワイヤー オブジェクトとビジネス オブジェクトの構成について:

ワイヤ オブジェクト- シリアル化され、マシン間 (クライアント/サーバーなど) 間でやり取りされるデータ。これは POCO オブジェクトです。

例えば：

ビジネス オブジェクト- 通常、一部またはすべてのプロパティをオン ワイヤー オブジェクトとして持つ別のクラスですが、いくつかの計算フィールドも持ちます。これは通常、「ワイヤー上」のオブジェクトの上にコンポジションを使用します。

オプション 2: 変換によるワイヤー オブジェクトとビジネス オブジェクト:

これはワイヤー オブジェクトで例 1 と同じですが、ビジネス オブジェクトでは合成を使用する代わりに翻訳を使用します。

オプション 3: ビジネス オブジェクトをまったく持たず、すべての計算を別の電卓クラスで実行します。注: 消費者は、通信中のオブジェクトと電卓を取得します

ここにベスト プラクティスやパターンがあるのか​​、それとも単にユーザーの好みの問題なのかについて、人々の意見を聞きたかったのです。

クライアント ライブラリから API に渡される「転送オブジェクト」(getter/setter のみの POJO) があるこのシナリオを考えると、転送オブジェクトに名前を付ける最良の方法は何ですか?

この例では、メイン クラスと転送オブジェクトの両方の名前がCar. 違うパッケージに入っていますが、同じ名前だと紛らわしいと思います。転送オブジェクトに名前を付ける方法に関するベスト プラクティスはありますか?

私が働いている場所では、このテーマについて何度も行ったり来たりして、健全性チェックを探しています。質問は次のとおりです。ビジネスオブジェクトはデータコンテナ（DTOのよ​​うなもの）である必要がありますか、それともそのオブジェクトでいくつかの機能を実行できるロジックも含まれている必要があります。

例-顧客オブジェクトを取り上げます。おそらくいくつかの一般的なプロパティ（名前、IDなど）が含まれていますが、その顧客オブジェクトには関数（保存、計算など）も含める必要がありますか？

1行の推論では、オブジェクトを機能（単一責任プリンシパル）から分離し、機能をビジネスロジックレイヤーまたはオブジェクトに配置します。

もう1つの理由は、いいえ、顧客オブジェクトがある場合は、Customer.Saveを呼び出して、それで完了します。オブジェクトを消費している場合、なぜ顧客を救う方法を知る必要があるのですか？

最後の2つのプロジェクトでは、オブジェクトが機能から分離されていましたが、新しいプロジェクトについて再び議論が行われています。どちらがより理にかなっていますか？

編集

これらの結果は、私たちの議論と非常によく似ています。どちらか一方に投票すると、方向が完全に変わります。他の誰かが彼らの2セントを追加したいですか？

編集

回答のサンプリングは少ないですが、ビジネスオブジェクトの機能は単純である限り許容できると大多数が信じているようですが、永続性は別のクラス/レイヤーに配置するのが最適です。これを試してみます。皆様のご意見ありがとうございました...