私たちのシステムでは、（Hibernateを使用して）データベースからORMマネージドエンティティBeanをフェッチし、次にそれらをDTO BeanにコピーしてUIに送ります。DTO javadocsをエンティティクラスから自動的に更新/コピー/継承
DTOのほとんどのプロパティはエンティティと同じ名前ですが、参照される関連エンティティはIDまたは別のDTOだけを格納するように変換する必要があるため、戻り値の型は異なることがあります。
私の理想的な夢の世界では、何とかエンティティのjavadocsを編集したとき、DTOの同じ名前のメソッドのjavadocが一致するように更新されます。これは、ビルドツールまたはEclipseプラグインを使用して行うことができます。
誰もこのようなことを見たことがありますか？
これは間違いなく可能です。必要なのはソースコードパーサーです。javaparserをお勧めします。
2つのVisitorsを書き込みます.1つはJavaDocsを読み込み、もう1つは書き込みます。両方で、あなたはおそらくメインクラスからこのすべてがアクセスできるようにし、ビルド中のmaven（Exec-Maven-Plugin）またはアリ（Java Task）を介して、メインクラスを呼び出すVoidVisitorAdapterと書き換えてpublic void visit(MethodDeclaration n, A arg)とpublic void visit(JavadocComment n, A arg)
で始まります。
ありがとう、それは唯一の答えであり、理論的にはうまくいくはずです。ありがとう。 –
あなたが望むものは不合理かもしれないと思います。
DTOはエンティティにマップされていないと考えられます。すべて同じであれば、なぜDTOが必要ですか？
エンティティの名前は通常、テーブル名にマップされ、フィールドは列にマップされます。エンティティのフィールド名を取得した場合は、ORMシステムのテーブルオブジェクトに簡単にアクセスできます。これは安全ではありません。
さらに、DTOは、UIのニーズや他の層のニーズに適応する柔軟性があると考えられています。つまり、データ転送、変換、組み合わせ、エンティティよりも少ないフィールドなどです。
など。リモートWebサービス呼び出しのために4つのエンティティまたはビューのデータを1つのDTOにまとめることができます。粗粒の処理のため、これはパフォーマンスの問題です。
結論として、エンタープライズレベルのJava EEアプリケーションであれば、DTOが非常に必要です。名前をコピーしたり、非常に依存するエンティティを持ちませんが、エンティティから派生してください。
私たちはどのような方法について話していますか？それがDTOなら、それはおそらくビジネスロジックなしのデータ構造です。 – slnowak