1

DAO/DTO デザイン パターンを使用してデータベースからデータを取得する、かなり大規模なアプリケーションを構築しています。アプリケーションでは、特定の DTO が「コア データ構造」になり、プロジェクト全体で参照されます。この DTO をプロジェクト全体に深く統合するのが良い方法なのか、それとも DTO を非 DTO オブジェクトに変換する何らかの変換レイヤーが必要なのか疑問に思っています。

この変換レイヤーを使用する理由と反対する理由がわかります。たとえば、変換レイヤーがある場合: 1) DTO を大幅に変更すると、プロジェクト全体でエラーが発生する可能性があるため、変換レイヤーを使用すると、エラーがコード内の 1 つのポイントに分離されます。2) 自動生成されるため、DTO に追加できないコア データ構造にロジックを追加できます。

ただし、変換レイヤーを持つことにも欠点があります。1) DTO が変更されるたびに、DTO 変換コードの一貫性を維持する必要があります。これにより、プログラマーが認識しなければならない別のステップが追加されるため、エラーが発生しやすくなります。2) ほとんどの場合、DTO のアクセサーをコピーしているため、これもコードの重複につながります。

最適なルートは何ですか? どこにでもあるDTOか、変換層か? 誰かが私を正しい方向に導くことができますか?

4

2 に答える 2

1

その名前が意図を与えると思います：データ転送オブジェクト。データ転送。

DTOの背後にある考え方は、DTOを使用して、ドメインモデルの外部、たとえば別のレイヤーに送信するデータをカプセル化することです。ロジックを公開するのではなく、データを送信するだけです。

ドメインオブジェクトがDTOの場合、ドメインロジックをドメインモデルの外部に公開するか、ドメインロジックをドメインオブジェクト以外の場所に保持します。または両方。

私はそれらを分離し続けるプロジェクトに携わってきましたし、それらをブレンドしたプロジェクトにも携わってきました。私は本当にそれらをブレンドすることをお勧めすることはできません。タイダイのように、レイヤーが混ざり始めます。

于 2011-04-22T03:01:32.007 に答える
0

DTOはアンチパターンのようなものだと思います。これは、EJB 1.0の永続性が非常に雑然としていて、ネットワークトラフィックを削減するためにDTOが必要だった時代の遺物です。

今、私はモデルオブジェクトを作成し、夜寝ると言います。DTOについて心配することができ、心配しない場合は、それらを不変にします。

アーキテクチャの純度を高めるための変換は、多くの価値を提供せずにCPUサイクルを浪費します。

于 2010-06-18T23:17:14.393 に答える