リモートサービスを使用してblazeds/java/jpaに接続するときにflexでDTOまたはドメインオブジェクトを使用する必要がありますか？

Question

私はJPAを使用して永続性を維持するJavaバックエンドを使用してAdobe Flexフロントエンドを開発しています。私が使用しているプロトコルは、BlazeDSで実装されたリモートオブジェクト（AMF）です。

私はサービスファサードとエンティティDAOを使い始めましたが、特定のDTOはありませんでした。同じPOJO（ドメインオブジェクト）は、Hibernate DAOに渡されるDTOとして使用されるものと同じサービスファサードで渡されました。

しかし、最近の数日は、これが良いアプローチであるかどうかを考えてきました。状況 Interesting JPA Pattern blog

：：私が読ん主題に関する最新の資料では、この1だった は、私は（つまり、それぞれの本は唯一、一つのカテゴリに関連付けることができPOJO Categoryと片方向ManyToOne関係でPOJO Book持っていると言います同じカテゴリは多くの書籍と関連している可能性があります）。私はいくつかの選択肢を参照してください。

オルタナティブ1： 私は方法/操作addUpdateBook(Book book)を公開します。この操作の実装では、本と参照カテゴリの両方を追加/更新します。つまり、クライアントが前から存在しないカテゴリを持つ書籍を提出すると、クライアントは暗黙的にaddUpdateBook操作を使用してカテゴリを編集できる可能性があります。

• クライアントはドメインモデルで直接作業しています。
• 新しい本がカテゴリを参照するには十分な

オルタナティブ2となるにもかかわらず 追加されたときに全体のカテゴリ情報が送信されます：私は、メソッド/操作addUpdateBook(Book book,Long categoryId)を公開 。実装では、指定されたcategoryIdのカテゴリを取得し、POJOという本で与えられたカテゴリを置き換えて、私はその本を永続させます。言い換えれば、ブックオブジェクト内のどのカテゴリも無視します。私はただcategoryIdを見ています。これは、クライアントがカテゴリを変更するために別の操作を使用する必要があることを意味します。

• プロ：クライアントがドメインモデルに多かれ少なかれ作業することができますが、...
• 詐欺：...それは本 オブジェクトのカテゴリは無視されることをクライアントのために混乱しています
• 詐欺：別の操作は、カテゴリの変更のために を使用する必要があるとき、それがより明確にすることが
• 詐欺：書籍のカテゴリ全体の情報は、サーバが
• プロそれを読みませんでしでも 場合、送信されます。 ：私はretriする必要がありますその本を永続させる前にカテゴリをイブしてください。 I これは若干のオーバーヘッドを意味すると推測します。

第三の選択： Iメソッド/操作addUpdateBook(BookDTO bookDto)を露出させます。 POJO BookDTOはPOJO Bookのように見えますが、フィールドCategory categoryの代わりにフィールドLong categoryIdがあります。実装では、私はBookを持続する前に、categoryIdのCategoryを取得します。

• プロ：（？）：メソッドが何を返すべきですgetBook(Long bookId)クライアント
• 詐欺のために混乱しませんか？それは BookDTOのみを返しますか？ 「 本の情報全体」を持たせるためには、の オペレーションも呼び出す必要があります。次に、クライアントは、 異なる部分を一緒にして本のローカルドメイン表現に設定する必要があります。 代替1と比較すると、これはクライアント側ではより複雑になります ？
• con：書籍を保持する前にカテゴリを取得する必要があります。 I これは若干のオーバーヘッドを意味すると推測します。
• con：クライアントのDTOを強制的に使用することにより、物理的な詳細が処理され、実際のドメインモデルからいくらか離れます。私は、ドメインモデルを持ち、ビジネス層でJPAを使用しているという点を見逃しているようです。

私は（！）代替3は、SOAコンテキストで操作を設計する方法だと思います。しかし、私にとっては、クライアントとサーバーの間に疎結合することはそれほど重要ではありません。私の焦点は、複数のクライアントプラットフォームのサポートを提供することではありません。

どの代替案を提案しますか？他にも良い選択肢がありますか？コード例のような素晴らしいリソースがあれば分かりますか？

Answer 1

「代替3」に関連するものを使用しています。最初はドメインオブジェクトを使用し始めました（おそらくdataservicesの私の経験のためです）。しばらくすると、問題が多すぎてDTOに切り替えました。すべてのパブリッシングサービスはDTOのみを公開しています（両方とも入出力パラメータ用）。

私は、ドメインオブジェクトとBlazeDSので直接作業中に会った問題のいくつか：

a）のドメインを分割する必要があるがために、プロパティを公開、またはプライベートコンストラクタをさらすようなカプセル化を（）オブジェクトそれらをデータ転送に使用してください。それ以外の場合は、独自のシリアライズ/デシリアライズを作成する必要があります。

b）クライアント/サーバー間のデータ変換を許可するには、トリックを使用する必要があります。たとえば、タイムゾーンの違いを防ぐために、日付ではなくusing stringsとします。またはint/doubleの代わりにusing stringsカスタムプロキシを記述することでこれらの問題のいくつかを解決できますが、他のデータ型の代わりに文字列を使用する方が簡単だと思います。

c）ほとんどの場合、ドメインオブジェクトからすべてのデータを取得する必要はなく、クライアントでのデータページネーション/遅延インスタンス化をサポートするさまざまなフレームワークを使用する必要があります。このフレームワークは複雑さを導入しており、私はそれを離れようとしています。

DTOを使用する主な欠点は、ドメインオブジェクト（DTO ...）間の変換を行うためのボイラーコードの量ですが、まだそれらを使用することをお勧めします。