Sulit untuk menetapkan praktik terbaik untuk sesuatu yang "fleksibel" atau abstrak sebagai DTO. Pada dasarnya, DTO hanya objek untuk transfer data tetapi tergantung pada tujuan atau alasan transfer, Anda mungkin ingin menerapkan "praktik terbaik" yang berbeda.
Saya merekomendasikan membaca Pola Arsitektur Aplikasi Perusahaan oleh Martin Fowler . Ada seluruh bab yang didedikasikan untuk pola, di mana DTO mendapatkan bagian yang sangat rinci.
Awalnya, mereka "dirancang" untuk digunakan dalam panggilan jarak jauh yang mahal, di mana Anda mungkin membutuhkan banyak data dari berbagai bagian logika Anda; DTO akan melakukan transfer data dalam satu panggilan.
Menurut penulis, DTO tidak dimaksudkan untuk digunakan di lingkungan lokal, tetapi beberapa orang menemukan kegunaannya. Biasanya mereka digunakan untuk mengumpulkan informasi dari POCO yang berbeda menjadi satu kesatuan untuk GUI, API, atau lapisan yang berbeda.
Sekarang, dengan pewarisan, penggunaan kembali kode lebih seperti efek samping dari warisan daripada tujuan utamanya; komposisi, di sisi lain, diimplementasikan dengan penggunaan kembali kode sebagai tujuan utama.
Beberapa orang merekomendasikan penggunaan komposisi dan pewarisan bersama, menggunakan kekuatan keduanya dan mencoba mengurangi kelemahan mereka. Berikut ini adalah bagian dari proses mental saya ketika memilih atau membuat DTO baru, atau kelas / objek baru dalam hal ini:
- Saya menggunakan warisan dengan DTO di dalam lapisan yang sama atau konteks yang sama. DTO tidak akan pernah mewarisi dari POCO, DTO BLL tidak akan pernah mewarisi dari DAL DTO, dll.
- Jika saya menemukan diri saya mencoba menyembunyikan bidang dari DTO, saya akan refactor dan mungkin menggunakan komposisi sebagai gantinya.
- Jika sangat sedikit bidang berbeda dari DTO basis yang saya butuhkan, saya akan meletakkannya dalam DTO universal. DTO Universal hanya digunakan secara internal.
- POCO / DTO dasar hampir tidak akan pernah digunakan untuk logika apa pun, dengan cara itu basis hanya menjawab kebutuhan anak-anaknya. Jika saya perlu menggunakan pangkalan, saya menghindari menambahkan bidang baru yang tidak akan pernah digunakan oleh anak-anaknya.
Beberapa dari mereka mungkin bukan praktik "terbaik", mereka bekerja cukup baik untuk proyek yang saya kerjakan tetapi Anda harus ingat bahwa tidak ada ukuran yang cocok untuk semua. Dalam hal DTO universal Anda harus berhati-hati, tanda tangan metode saya terlihat seperti ini:
public void DoSomething(BaseDTO base) {
//Some code
}
Jika ada metode yang membutuhkan DTO sendiri, saya melakukan pewarisan dan biasanya satu-satunya perubahan yang perlu saya lakukan adalah parameter, meskipun kadang-kadang saya perlu menggali lebih dalam untuk kasus-kasus tertentu.
Dari komentar Anda, saya mengerti bahwa Anda menggunakan DTO bersarang. Jika DTO bersarang Anda hanya terdiri dari daftar DTO lain, saya pikir hal terbaik untuk dilakukan adalah membuka daftar.
Bergantung pada jumlah data yang perlu Anda tampilkan atau kerjakan, mungkin merupakan ide bagus untuk membuat DTO baru yang membatasi data; misalnya, jika UserDTO Anda memiliki banyak bidang dan Anda hanya perlu 1 atau 2, mungkin lebih baik memiliki DTO dengan hanya bidang tersebut. Mendefinisikan layer, konteks, penggunaan dan utilitas DTO akan banyak membantu ketika mendesainnya.