問題タブ [data-transfer-objects]

場合によっては、同じリソースに対して複数のDTOが必要になることがよくあります。

フォトアルバムを例にとってみましょう。表示したいものに応じて、DTOに異なるデータが必要になります（フォーム、リスト、詳細などによる作成）。

アルバムを作成するためのalbumFormDTO、アルバムのリストのためのalbumDTOコレクション、および詳細なアルバムのためのalbumDetailDTOがあります。

それぞれについて、特定のアセンブラが必要です。そのようにするのは本当に重いようです。

ばかげているように見えますか？

ありがとう、CyaBenjamin。

一連の規則（たとえば、すべてのパブリックプロパティ）を使用して、ビジネスオブジェクト（データのマッピングではなくタイプ定義）からデータ転送オブジェクトを生成するための最良のアプローチを探しています。

これは、dtoがビジネスオブジェクトに似ていない多くの場合（多数のビジネスオブジェクトを単一のデータ転送オブジェクトにフラット化する場合など）には不可能であるか、望ましくない場合があることを認識しています。

ただし、私の場合、データ転送オブジェクトの大部分はビジネスオブジェクトと非常によく似ています（特にデータを更新するためのDTOの場合）。

既存のコード生成ツール（CodeSmithのような汎用コード生成ツールだけでなく、既存のテンプレートを使用した特定のソリューションを探しています）、または動的アセンブリ作成ツール（たとえば、内部でReflection Emitを使用）があるかどうか疑問に思っていましたか？または、これが以前に行ったことである場合は、さまざまなオプションを決定するのにどのテクニックを使用したかについて知りたいと思います。

私は今日、理由を実際に尋ねることなく、何年もの間この要件を盲目的に守ってきたことに気づきました。今日、私は最初から作成したモデルオブジェクトでNotSerializableExceptionに遭遇し、十分であることに気づきました。

これは負荷分散サーバー間のセッションレプリケーションが原因であると言われましたが、Serializableを実装していない他のオブジェクトをセッションスコープで見たことがあります。これが本当の理由ですか？

これはおそらく古くからの質問だと思いますが、より良い方法は何ですか？アプリケーションのすべてのレイヤーでドメインモデルオブジェクトを使用し、JSPで値をそれらに直接バインドすることもできます（私はJSFを使用しています）。または、ドメインモデルオブジェクトをDAOまたはサービスレイヤーでDTOに変換し、軽量のDTOをプレゼンテーションレイヤーに送信します。

データベースを変更するとすべてのDTOが変更されるのに対し、どこでもモデルオブジェクトを使用するには、影響を受けるモデルオブジェクトを変更するだけでよいため、DTOを使用するのは意味がないと言われています。ただし、DTOの使いやすさと軽量性はそれを上回っているようです。

私のアプリはHibernateモデルオブジェクトを使用し、独自にカスタム作成されたモデルオブジェクトを使用していることに注意してください（つまり、DBセッションにバインドされず、常にデタッチされます）。上記のシナリオのいずれかが、厳密なモデルオブジェクトパターンにとってより有益ですか？Hibernateの使用は、LazyInitializationExceptionsなどに関して非常に大きなPITAでした。

私はさらに議論を進めることを期待してこの質問を編集しています（私がこれを正しく行っているかどうかはわかりません）：

私がモデルオブジェクトで抱えている問題は、それらがまったく柔軟ではないということです。以下のコメントは、モデルオブジェクトがすべてのレイヤーで使用できるようにアプリケーションを設計する必要があることを示しています。なんで？ユーザーがばかげた機能の一部を望んでいる場合、私は彼らに「それはモデルオブジェクトでは機能しない」と言うことになっていますか？

単純明快で、モデルオブジェクトが機能しない場合があります。あなたが持っているかもしれません：

しかし、多分あなたはそのすべての情報を必要としないでしょう。必要なのは、教師の名前、今年教える生徒の数、およびすべての生徒の平均GPAを合わせたものだけです。その場合はどうしますか？完全な教師情報と生徒の関係を取得すると、コードは生徒のリストにカウントされ、内部のすべてのGPAの合計平均を計算しますか？これは、「String lastName」、「int numStudents」、および「doublecombinedGpa」を使用してDTOを作成するよりも手間がかかるようです。

これらについては決心しているように聞こえるかもしれませんが、モデルオブジェクトをすべてのインスタンスで完全にクリーンに使用できるアプリケーションではまだ作業していません。異常なユーザー要求を伴う通常の実際のアプリケーションは、そのようには機能しません。

次のドメイン エンティティがあります。

私は次のDTOを持っています:

現在のワークフローは非常に単純です。私のリポジトリは CartItem 型の IEnumerable を返します。私のサービスはそれを dto (CartItemDTO) に変換します。私のコントローラーはそれをビューに渡します。ここまでは順調ですね。

ここで、各項目の合計を実装したいと考えています。次のプロパティを CartItemDTO に追加しました。

次に、次のコードを CartItemDTO コンストラクターに追加しました。

私の最初の質問は、これがベスト プラクティスのアプローチであるかどうかです。そうでない場合、なぜですか？Total プロパティを別の場所に追加する必要がありましたか? もしそうなら、なぜですか？

また、カート全体の合計を実装したかったので、新しいクラス (以下) を作成し、それを返すようにサービスを変更しました。

これで、新しいクラスをビューに渡すか、別の ViewModel を作成して新しいクラスのコンテンツを ViewModel に渡し、それをビューに渡すことができます。

2 番目の質問は、このアプローチがベスト プラクティスのアプローチであるかどうかです。そうでない場合、なぜ、何を別の方法で行う必要があったのでしょうか?

次の例を検討してください。

ここで、User クラスに CompanyCode プロパティを持たせたいと考えています。最初の明らかな解決策は、単に User クラスに CompanyCode プロパティを配置することです。

ここでの問題は冗長性です。これは、Company クラスにプロパティ CompanyCode が既に存在するためです。ユーザーが Company クラスを継承せずに Company の CompanyCode プロパティを使用できるようにする方法はありますか (ここでの問題は、C# がクラスの多重継承を許可していないことです)。 ICompany インターフェイスを使用します (ただし、値オブジェクトではインターフェイスが面倒です)。Company クラスを User クラスに含めることだけを考えていますが、適切な CompanyCode のみを使用します。

このようなもの..

しかし、文字列プロパティ CompanyCode を追加するだけでも違いはありません。皆さんのアドバイスが必要です。前もって感謝します..

Azure Web ロール ASP プロジェクトでホストされている Silverlight アプリがあります。ASP プロジェクトは、WCF サービスを公開します。

データ型のクラス定義の 1 つのセットが必要です。誰かが 3 番目のプロジェクト (クラス ライブラリ) を作成し、SL と ASP からの参照を追加することを勧めました。私はこれを始めましたが、Silverlight プロジェクトは、Silverlight プロジェクトへの参照しか追加できないと不満を漏らしました。

次に、Silverlight クラス ライブラリを作成し、データ クラスをそこに移動しました。ただし、Windows Azure ストレージ クライアントなどへの .dll 参照を追加する必要があります。次に、Silverlight クラス ライブラリは、Silverlight 4 対応の .dll への参照しか追加できないことを教えてくれますが、Windows Azure はその 1 つではありません。素晴らしい。

これを回避するためにできることはありますか、それともあまり洗練されていない冗長なソリューションで立ち往生していますか?

動機と実装の面で、 DTO パターン(Fowler による) とMemento パターン(GoF による)の違いは何ですか? 同じクラスでもいいですか？はいの場合、どのように名前を付けることができますか (xxxDTO または xxxMemento)? 実装に主な違いはありますか? MVPアーキテクチャのどこに位置するのでしょうか?

ありがとう。

この質問で説明されているように、HibernateエンティティとWebサービスによって返されるデータ転送オブジェクトの間で変換する方法について同様の質問と懸念がありました。

ベストプラクティスと見なされるejb3でデータ転送オブジェクトを使用しています

ここで言及されている要因の1つは、ドメインモデルが変更された場合、一連のDTOがWebサービスの場合に消費者を保護することです。

私のプロジェクトにかなりの量のコードが追加されるように見えますが、この推論は正しいようです。

Hibernateエンティティ（インターフェイスを実装する）を同じインターフェイスを実装するDTOに変換するために使用できる優れたデザインパターンはありますか？

したがって、次の両方が「Book」を実装すると仮定すると、JAXBをシリアル化して返すことができるように、BookEntity.classをBookDTO.classに変換する必要があります。

繰り返しになりますが、この見通し全体は私には疑わしいようですが、この変換に対処するのに役立つ良いパターンがそこにある場合は、いくつかの洞察を得たいと思います。

リフレクションを介して変換するための興味深い方法はありますか？または、私が考えていない「ビルダー」パターン？

DTOパターンを無視して、エンティティを渡す必要がありますか？

DTO/BO について私が疑問に思っていることの 1 つは、いつ DTO を渡す/返すか、いつ BO を渡す/返すかということです。

私の直感によると、常に NHibernate を BO ではなく DTO にマップし、常に DTO を渡したり返したりするように指示されています。その後、ビジネス ロジックを実行する必要があるときはいつでも、DTO を BO に変換していました。

これを行う方法は、BO に、DTO と BO の両方が唯一の引数として実装するインターフェイスの型 (必要なフィールド/プロパティを定義する) であるパラメーターを受け取るコンストラクターを持たせることです。

次に、コンストラクターで DTO を渡すことで BO を作成し (両方とも同じインターフェイスを実装しているため、両方とも同じプロパティを持っているため)、その BO でビジネス ロジックを実行できます。BO を DTO に変換する方法もあります。

しかし、人々が BO のみを操作し、バックグラウンドで DTO のみを操作しているように見える場所も見てきましたが、ユーザーには DTO がないように見えます。

常に BO を使用する場合と比較して、このアーキテクチャにはどのような利点/欠点がありますか?

私は常に DTO または BO のいずれかを渡したり返したりする必要がありますか、または組み合わせて一致させる必要がありますか (混合と一致は混乱を招く可能性があるようです)。