問題タブ [dto]

JAX-RS アプリケーションのメソッドがドメイン オブジェクトを返す場合、表現 (JSON など) にはこのオブジェクトのすべての属性が含まれます。しかし、このオブジェクトに Web に公開すべきではない「プライベート」データが含まれている場合はどうなるでしょうか。

また、外部から内部への別の方向性についてはどうでしょうか: プライベート フィールドがオーバーライドされるのをどのように防ぐことができるでしょうか?

これに対する唯一の解決策は、データ転送オブジェクト (dto) を作成することです。

マップするフィールドを指定できない場合を除き、「 automapper 」を使用しても解決にはなりません。

では、JAX-RS は開発者に DTO の作成を強制するのでしょうか? それとも別の解決策がありますか？

I need to synchronize two databases. Those databases stores same semantic objects but physically different across two databases.

I plan to use a DTO Pattern to uniformize object representation :

DB ----> DTO ----> MAPPING (Getters / Setters) ----> DTO ----> DB

I think it's a better idea than physically synchronize using SQL Query on each side, I use hibernate to add abstraction, and synchronize object.

Do you think, it's a good idea ?

標準のドメイン層エンティティがあります。

ある種の検証属性が適用されています。

ご覧のとおり、これらの属性は完全に構成されています。ここで使用されている検証フレームワーク (NHibernate Validator、DataAnnotations、ValidationApplicationBlock、Castle Validator など) は重要ではありません。

クライアント レイヤーには、ドメイン エンティティ自体を使用せずに、ビュー レイヤーが使用する ViewModel (別名 DTO) にマップする標準的なセットアップもあります。

次に、クライアント/ビューでいくつかの基本的なプロパティ レベルの検証を実行できるようにしたいとしましょう。

これを行う唯一の方法は、ViewModel オブジェクトで検証定義を繰り返すことです。

ViewModel (DTO) レイヤーでビジネス ロジック (プロパティ レベルの検証) を繰り返したので、これは明らかに満足のいくものではありません。

では、何ができるでしょうか？

AutoMapper のような自動化ツールを使用して Domain エンティティを ViewModel DTO にマップすると仮定すると、マップされたプロパティの検証ロジックを ViewModel に転送するのもクールではないでしょうか?

質問は次のとおりです。

1) これは良い考えですか?

2) もしそうなら、それはできますか? そうでない場合、代替手段は何ですか？

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

最近、私たちのコードでこのパターン (?) に出くわしました。BlazeDS を使用した Spring アプリと Flex フロントエンドがあります。次のように、DTO でインターフェイスを使用することが決定されました。

ジャワ

アクションスクリプト

DTO のインターフェースは何をもたらしますか? これらは、ロジックがまったくない軽量オブジェクトです。DTO は理にかなっており、インターフェイスは理にかなっていますが、一緒ではありません。

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

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

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

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

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

ありがとう、CyaBenjamin。

まず第一に、いくつかのコンテキスト：

ModelBinderに組み込まれているMVCによってオブジェクトに自動的に実体化されるいくつかのオブジェクトをポストバックするフォームがあります。

さらに、DTO（DataTransferObjects）に投稿していることを強調したいと思います。これは、ラインマップをさらに下のエンティティフレームワークエンティティに変換するため、属性を追加する以外は、DTOの変更を望まないためです。

問題

ユーザーが「時間」に無効な値、たとえば「Fubar」を入力した場合、ModelBinderは当然「時間」プロパティを設定しようとしません。ただし、これはintであり、文字列ではないため、デフォルトは0です。

もちろん、これは私にとっていくつかの困難を引き起こします。ユーザーが実際に0を入力したのか、それとも無効な入力が原因であるのかがわからないためです。

ホームロールされたオブジェクトからエンティティ（Entity Framework）マッパーを使用しているため、「時間」プロパティのフットプリントをintに変更できませんか？。MVCには検証が組み込まれていることは承知していますが、MVCが激しく攻撃されており、ASP.NET MVC 2.0で新しい検証が行われることがわかっているため、実装はしません。

解決？

どのフィールドが正しくないかをユーザーに指摘できる必要があります。つまり、何らかのロジックを実行して新しいものをポストバックできる例外（または他の独創的な解決策？）をキャッチできる必要があります。ユーザーが間違ったことを明確にしたところをユーザーに表示します。

私の現在のアイデア：カスタムModelBinderを作成します。

何を指示してるんですか？

基本的なセッターとゲッター以外の機能を DTO に入れることは適切ですか?

バックグラウンド

私たちは独自のビジネス オブジェクト アーキテクチャを持っています。これは、同様の使用法、検証、包括的な DAL などを備えた「CSLA」ビジネス オブジェクト フレームワークのはるかに軽量な (...大まかに基づいていますが、実際には使用していません...) バージョンです。すべてコードが生成されます (ストアド プロシージャとビジネス オブジェクトは CodeSmith を使用して作成されます)

ビジネス オブジェクトは、オブジェクトを取得する機能、オブジェクトおよび汎用リストを返すためのフィルター ソート パラメータを備えたリスト機能に関して非常に豊富です。

このアーキテクチャは、特定のアーキテクチャや一般的なアーキテクチャや純粋主義に同意していない可能性がありますが、私たちにとってはうまく機能し、多くの手動コーディングを削減しました。

特に他のシステム (サードパーティ、Flash、Silverlight など) と統合する場合に多く見られることの 1 つは、コンテキスト化された「基本オブジェクト」または特定の目的のために Web サービスなどで簡単にシリアル化して提供できるデータ コンテナーの要件です。

SO や Web を見回すと、DTO という用語がよく出てきます。これらの基本オブジェクトは、Dto 名前空間内に作成されています。これらのオブジェクトは、ビジネス オブジェクトの基本または特定のバージョンを表す基本オブジェクトですが、DataRow またはビジネス オブジェクトのいずれかを受け入れて「Dto」オブジェクトを設定するコンストラクター以外の機能はありません。

質問:

1)これを「DTO」オブジェクトと呼ぶのは正しいですか?

2)データを提供し、オブジェクトのプロパティを設定するコンストラクターを持つのではなく、この人口コードが別のクラス、ある種の「ヘルパー クラス」にある必要があります。

私がやろうとしていることの用語と命名規則に関するコメントはありますか?

ありがとう

私は豊富なドメイン モデルを持っています。ほとんどのクラスには、メンバー オブジェクトのプロパティを計算するか公開する (つまり、これらのプロパティの値は永続化されません) いくつかの動作といくつかのプロパティがあります。

私のクライアントは、WCF 経由でのみサーバーと通信します。

そのため、各ドメイン エンティティに対して、対応する DTO (データのみを含む単純な表現) とDtoMapper<DTO,Entity>、静的ゲートウェイを介してエンティティを DTO に相当するものに、またはその逆に変換できるマッパー クラスを実装しています。

このアプリケーションのサーバー側は主に持続性に関するもので、WCF サービスから取得した DTO が逆シリアル化され、任意の ORM がそれらをデータベースに保持するか、クエリ要求が WCF から受信され、ORM がそのクエリを実行します。 DB を返し、WCF によってシリアル化されて送り返されるオブジェクトを返します。

このシナリオを考えると、永続ストアをドメイン エンティティにマップすることは意味がありますか? それとも DTO に直接マップする必要がありますか?

ドメインエンティティを使用する場合、フローは次のようになります

1. クライアント要求オブジェクト
2. WCF は要求をサーバーに送信します
3. ORM はデータベースにクエリを実行し、ドメイン エンティティを返します
4. マッパーによって DTO に変換されたドメイン エンティティ
5. WCF は DTO をシリアル化し、クライアントに返します
6. クライアントは DTO を逆シリアル化します
7. マッパーによってドメインエンティティに変換された DTO
8. 作成されたビューモデルなど

帰りも同様

DTO に直接マップすると、オブジェクトごと、要求ごとに 1 つのマッピングを削除できます。これを行うことで何を失うのですか？

頭に浮かぶ唯一のことは、挿入/更新の前に検証する別の機会です.DTOが検証の対象であったか、ネットワークを介して送信される前にドメインエンティティとして存在していたという保証はありません.選択時に検証します (別のプロセスがデータベースに無効な値を入れた可能性がある場合)。他の理由はありますか？これらの理由は、追加のマッピング手順を正当化するのに十分ですか?

編集：

上記で「任意の ORM」と言いましたが、可能な限り ORM と永続性にとらわれないようにしたいと思っていますが、NHibernate に固有の何か特別なものを追加する必要がある場合は、必ずそうしてください。

DTO のデータに基づいて派生した値を返すインスタンス メソッドを DTO が持つことは許容されますか? それとも、DTO は追加のメソッド (ゲッター/セッター以外) を持たない純粋なデータ コンテナーにする必要がありますか?

私の純粋主義者は、ビジネスロジックがそのような方法に忍び込むのは簡単ではないと言います。ただし、(たとえば) DTO がアプリケーション層全体で共有されている場合、DTO でそのようなメソッドを使用することについて議論があるかもしれません。

これについてどう思いますか。それが許容される状況はありますか、それともこの種のことを避けるべきですか? そして、なぜ/なぜしないのですか？