Apa gunanya menggunakan DTO (Data Transfer Objects)?

132

Apa gunanya menggunakan DTO dan apakah itu konsep yang ketinggalan zaman ? Saya menggunakan POJO di lapisan tampilan untuk mentransfer dan mempertahankan data. Bisakah POJO ini dianggap sebagai alternatif untuk DTO?

java design-patterns

— Vinoth Kumar CM
sumber

10

Tapi POJO bisa menjadi DTO dan DTO dapat diimplementasikan dengan POJO. Anda adalah apel dan jeruk comparign.

— Euforia

3

Mengapa ide bagus menjadi ketinggalan jaman? Lihatlah Lisp. Terlepas dari lelucon, saya setuju dengan Euphoric: Saya biasanya menerapkan DTO menggunakan POJO. Saya masih menemukan DTO sangat sederhana (KISS) dan konsep yang berguna.

— Giorgio

Tidak ada gunanya, ini anti-pola, lihat: Data Transfer Object Is a Shame

— yegor256

115

DTO adalah sebuah pola dan itu adalah implementasi (POJO / POCO) independen. DTO mengatakan, karena setiap panggilan ke antarmuka jarak jauh mahal, respons untuk setiap panggilan harus membawa data sebanyak mungkin. Jadi, jika beberapa permintaan diperlukan untuk membawa data untuk tugas tertentu, data yang akan dibawa dapat digabungkan dalam DTO sehingga hanya satu permintaan yang dapat membawa semua data yang diperlukan. Katalog Pola Arsitektur Aplikasi Perusahaan memiliki rincian lebih lanjut.

DTO adalah konsep dasar, bukan ketinggalan jaman.

— theD
sumber

9

Anda mungkin menemukan mereka dengan nama yang berbeda, karena semua orang tampaknya menciptakan kembali roda hari ini

— linkerro

3

Seperti "Nilai Objek".

— theD

2

@linkerro: Benar: Saya pikir banyak orang harus menghabiskan lebih banyak waktu untuk membaca tentang hal-hal yang telah ditemukan daripada menciptakan kembali sendiri. Barang yang diciptakan kembali akan selalu kurang matang.

— Giorgio

10

@Giorgio Ada banyak pengembang di luar sana yang masih menjalankan ide-ide yang seharusnya tidak pernah berhasil. Saya berharap lebih banyak devs mempertanyakan setiap ide yang mereka baca.

— Erik Reppen

59

DTO sebagai konsep (objek yang tujuannya adalah untuk mengumpulkan data yang akan dikembalikan ke klien oleh server) tentu tidak ketinggalan jaman.

Apa yang agak ketinggalan jaman adalah gagasan memiliki DTO yang tidak mengandung logika sama sekali, digunakan hanya untuk mentransmisikan data dan "memetakan" dari objek domain sebelum dikirim ke klien, dan di sana dipetakan untuk melihat model sebelum meneruskannya ke lapisan tampilan. Dalam aplikasi sederhana, objek domain sering dapat langsung digunakan kembali sebagai DTO dan diteruskan langsung ke lapisan tampilan, sehingga hanya ada satu model data terpadu. Untuk aplikasi yang lebih kompleks, Anda tidak ingin memaparkan seluruh model domain ke klien, sehingga pemetaan dari model domain ke DTO diperlukan. Memiliki model tampilan terpisah yang menduplikasi data dari DTO hampir tidak pernah masuk akal.

Namun, alasan mengapa gagasan ini sudah ketinggalan zaman daripada sekadar salah adalah bahwa beberapa kerangka kerja / teknologi memerlukannya, karena domain dan model tampilan mereka bukan POJOS dan sebagai gantinya terikat langsung ke kerangka tersebut.

Terutama, Entity Beans di J2EE sebelum standar EJB 3 bukan POJO dan sebaliknya objek proxy yang dibuat oleh server aplikasi - tidak mungkin mengirimnya ke klien, jadi Anda tidak punya pilihan untuk menyewa lapisan DTO terpisah - itu wajib.

— Michael Borgwardt
sumber

2

Sebagai dev UI dipaksa menjadi peran yang lebih umum saya pasti menemukan fenomena Mapper.Map di basis kode kami membodohi. Mengapa DTO tidak bisa hanya memetakannya sendiri?

— Erik Reppen

1

@ErikReppen Manfaat utama adalah memisahkan model domain & DTO Anda. Jika DTO Anda memetakan sendiri, itu perlu referensi ke model domain Anda.

— Alexander Derck

17

Meskipun DTO bukan pola yang ketinggalan zaman, ia sering diterapkan secara tidak perlu, yang mungkin membuatnya tampak ketinggalan zaman.

Pola yang paling disalahgunakan dalam komunitas Java Enterprise adalah DTO. DTO jelas didefinisikan sebagai solusi untuk masalah distribusi. DTO dimaksudkan sebagai wadah data berbutir kasar yang secara efisien mengangkut data antar proses (tingkatan). ~ Adam Bien

Misalnya, Anda memiliki JSF ManagedBean. Pertanyaan umum adalah apakah kacang harus memegang referensi ke Entitas JPA secara langsung, atau haruskah mempertahankan referensi ke beberapa objek perantara yang kemudian dikonversi ke Entitas. Saya telah mendengar objek perantara ini yang disebut sebagai DTO, tetapi jika ManagedBeans dan Entitas Anda beroperasi dalam JVM yang sama, maka ada sedikit manfaat menggunakan pola DTO.

Pertimbangkan anotasi Validasi Bean. Entitas JPA Anda kemungkinan dijelaskan dengan validasi @NotNull dan @Size. Jika Anda menggunakan DTO, Anda ingin mengulangi validasi ini di DTO Anda sehingga klien yang menggunakan antarmuka jarak jauh Anda tidak perlu mengirim pesan untuk mengetahui bahwa mereka gagal validasi dasar. Bayangkan semua kerja ekstra untuk menyalin anotasi Validasi Bean antara DTO dan Entitas Anda, tetapi jika View dan Entitas Anda beroperasi dalam JVM yang sama, tidak perlu mengambil pekerjaan tambahan ini: cukup gunakan Entitas.

Tautan IAmTheDude ke Katalog Pola Arsitektur Aplikasi Perusahaan memberikan penjelasan singkat tentang DTO, dan di sini ada lebih banyak referensi yang saya temukan menerangi:

— DavidS
sumber

3

Ada kalimat: "..., tetapi jika ManagedBeans dan Entitas Anda beroperasi dalam JVM yang sama, maka ada sedikit manfaat menggunakan pola DTO" . Ada banyak aplikasi menengah di perusahaan di luar sana yang secara bodoh menerapkan pola DTO tanpa manfaat apa pun. Itu hanya menambahkan "copy layer" yang tidak berguna. Orang-orang yang menciptakan sistem ini tidak menyadari bahwa manajer entitas Java EE 5+ melepaskan entitas ketika transaksi berakhir dan menjadikannya DTO yang sebenarnya. Jadi, untuk webapp JVM tunggal, jenis pola sudah usang . Tampaknya menjadi peninggalan pengembang backend J2EE ...

— Kawu

Tapi apa itu "JSF ManagedBean" dan "JPA Entity"? Jika mereka tidak ketinggalan zaman, maka Anda harus dapat menjelaskannya menggunakan kerangka dan istilah agnostik bahasa.

— U Avalos

8

Benar-benar tidak! Baru-baru ini saya belajar tentang lebih baik menggunakan DTO daripada objek bisnis yang Anda gunakan (mungkin terikat dengan mapper ORM Anda).

Namun, gunakan saja ketika mereka layak untuk digunakan dan bukan hanya demi menggunakannya karena mereka disebutkan dalam beberapa buku pola yang baik.
Contoh khas yang baru saja terlintas di pikiran saya adalah ketika Anda mengekspos semacam antarmuka ke pihak ke-3. Dalam skenario seperti itu Anda ingin menjaga objek yang dipertukarkan cukup stabil yang biasanya dapat Anda capai dengan baik dengan DTO.

— Juri
sumber

1

Satu tempat yang saya temukan DTO sangat berguna adalah berisi logika untuk respons API. Dengan pola ini, mudah untuk mengelola berbagai jenis respons dari objek ke berbagai format dengan cara yang dapat diuji. Dengan menggunakan pola ini pada peran saya saat ini, kami dapat mulai menguji format respons untuk API kami yang telah bernilai karena tumpukan kami menjadi lebih isomorfik dengan berbagai klien (http / seluler). Jelas tidak ketinggalan jaman.

— zquintana
sumber