明らかにすべてのシナリオを単一のデザインでカバーできるわけではありませんが、ORMクラスはプレゼンテーションとビジネスレイヤの間を往復する必要がありますリモート）、データ転送オブジェクトの必要性を置き換える？ ORMクラスを使用することで、不必要な負荷、コンテキスト管理の問題、タイトなカップリングの問題が発生しますが、時間が大幅に節約され、操作が簡単になります。今では、一般的には他のものより優位に立つ標準的なアプローチがありますか？ejb3のデータ転送オブジェクトをベストプラクティスとみなしています
これは非常に興味深い質問です。私は2年以上にわたって調査し、実験してきました。
私は本当にここに正解か間違った答えがないと思います。なぜなら、典型的には、クライアントが何であるか（ウェブページ、ws、マシンおよび/またはローカル、リモート）に応じてハイブリッドを望むかもしれないからです。
ここで覚えておくべき重要なことは、各オファーに賛否両論があり、あなたの要件に基づいてこれを適用することです。例については
：
システムをレイヤーにラップし、慎重に公開して保護することで、さまざまなタイプの多くのクライアント向けにさまざまなAPIを作成できます。
DTOの存在は、JPA/Hibernateに関連すると思います脆弱性です。透過的に遅延初期化を行うことができれば、決してそれらを使用しません。したがって、DTOを使用することは、私のドメイン/ワークスペースが常に失われる契約です（どこでも複製できます）。 合計を使用することはできますが、それらを嫌う必要があります:)
タイトカップリング？説明してください。
私の場合、DTOはアンチパターンです。 EJB3では、EJB3を使用することを省略できます。エンティティをクライアントに送信する前に、怠惰な初期化を強制することができます。
もちろん、クライアントに送信するフィールドが2つだけ必要な場合は、それらを送信してください。しかし、私の現在のプロジェクトのようにすべてのコピーが常にある場合は、そのDTOを取り除こうとします。私はそれらを使用する理由はありません。クライアントが要求したときにビジネスオブジェクトをクライアントに送信します。なぜラッパーを使用するのですか？
私は最後の "スピーカー"に同意します。なぜejb3でラッパーを使用するのですか？私たちはDTOなしで非常に複雑なシステムを構築しますが、それを発見したエンティティ（JPA）を使用します。それは明らかでした...
GUIコントローラがオブジェクトのプロパティをオブジェクトのプロパティではなくフォームに送信すると、エンティティのみで問題なく動作します。一方、エンティティが使用され、これらのエンティティが多対1の関係を持つ場合、エンティティがエンティティマネージャによって熱心に取り出されない場合、いくつかの厄介な例外が見られるはずです。
このような状況は、たとえばSpring MVCのタグ、または他のGUIコンポーネントの同様の構造をタグに取り込もうとするときに発生します。さらに
は、のDTOは、そのような検証注釈やJAXBなどの余分な注釈を配置するための非常に良い場所ですなど私は、プレゼンテーション層でエンティティを使用してに対して、いくつかの問題があります。
ロックイン：これにより、プレゼンテーションとモデルの間に緊密なロックインが作成されます。大規模なプロジェクトでも、いずれかを変更するのは高価になり、不可能にさえなります。現代の道具はそれほどまだありません。
セキュリティ：モデルオブジェクトを使用すると、さまざまなデータベースID情報をWebページに簡単に転送できます。これは明らかなセキュリティ上の問題です。 dto:sを使用すると、をサーバーで非常にシンプルなセッションマップで非表示にすることができます。
必要性の違い：GUIビューはモデルオブジェクトの直接のリストであることはめったにありません。多くの場合、彼らはより多くの、獣を結合した、guishです。 GUIのニーズは、あなたのモデルを曖昧にする傾向があります。
スピード：エンティティでは、すべてのフィールドが読み書きされるたびに処理されます。プレゼンテーションレイヤーに直接渡すので、JPAクエリを最適化しようとするのは難しいです。ほとんど不可能です。私は間違いなく、将来のプロジェクトでmyBatisのようなJDBCアクセスを直接行うつもりです。したがって、ORMを排除する。
は、私があまりにもDTO:sに対して問題を抱えています。
すべてのプロジェクトでdto:sを使用して投票しますので、JPAも削除します。私のDAOのサービスのための