Apakah praktik yang baik untuk menggunakan objek entitas sebagai objek transfer data?

Terserah Anda.

Kebanyakan orang akan mengatakan kepada Anda bahwa ini bukan praktik yang baik, tetapi Anda bisa lolos dalam beberapa kasus.

EF tidak pernah bermain baik dengan DDD karena berbagai alasan, tetapi dua alasan yang menonjol: Anda tidak dapat memiliki konstruktor parameter pada entitas Anda dan Anda tidak dapat mengenkapsulasi koleksi. DDD bergantung pada hal itu, karena model domain harus mencakup data dan perilaku.

Di satu sisi, EF memaksa Anda untuk memiliki model domain anemik dan dalam hal ini Anda dapat menggunakan entitas sebagai DTO. Anda mungkin mengalami beberapa masalah jika Anda menggunakan properti navigasi tetapi Anda dapat melakukan serialisasi entitas tersebut dan mengirimkannya melalui kabel. Ini mungkin tidak praktis. Anda harus mengontrol serialisasi untuk setiap entitas yang memiliki properti yang tidak perlu Anda kirimkan. Cara yang lebih mudah adalah dengan mendesain kelas-kelas terpisah yang disesuaikan untuk transfer data. Pustaka seperti AutoMapper dibuat untuk tujuan ini.

Sebagai contoh: Misalkan Anda memiliki kelas bernama Person dengan definisi berikut:

public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime DateOfBirth { get; get; }

    // plus a bunch of other properties relevant about a person
}

Dengan asumsi Anda ingin menampilkan daftar karyawan di suatu tempat, mungkin praktis untuk mengirim hanya Id, FirstName dan LastName. Tetapi Anda harus mengirimkan semua properti lain yang tidak relevan. Ini bukan masalah besar jika Anda tidak peduli dengan ukuran respons, tetapi ide umumnya adalah hanya mengirim data yang relevan. Di sisi lain, Anda mungkin mendesain API yang mengembalikan daftar orang dan dalam hal ini mengirim semua properti mungkin diperlukan, sehingga masuk akal untuk melakukan serialisasi dan mengirim entitas. Dalam hal ini, membuat kelas DTO masih bisa diperdebatkan. Beberapa orang suka mencampurkan entitas dan DTO, beberapa orang tidak suka.

Untuk menjawab pertanyaan terbaru Anda, EF adalah ORM. Tugasnya adalah memetakan record database ke objek dan sebaliknya. Apa yang Anda lakukan dengan objek-objek tersebut sebelum dan sesudah melewati EF bukanlah bagian dari perhatiannya. Juga tidak seharusnya.

Tidak, tidak.

Idealnya, DTO akan cocok dengan repositori persistensi Anda (alias, tabel database Anda).

Tetapi kelas bisnis Anda belum tentu cocok. Anda mungkin memerlukan kelas tambahan, atau terpisah, atau kelas yang digabungkan dengan apa yang Anda miliki di database. Jika aplikasi Anda kecil, Anda mungkin tidak terlalu melihat masalah seperti ini, tetapi dalam aplikasi menengah hingga besar, ini akan sering terjadi.

Hal lainnya adalah bahwa DTO adalah bagian dari domain apapun yang berhubungan dengan persistence, sementara Business Layer Anda seharusnya tidak tahu apa-apa tentang mereka.

Ini sebenarnya ide yang sangat buruk. Martin Fowler memiliki sebuah artikel tentang DTO Lokal.

Singkat cerita, Pola DTO digunakan untuk mentransfer data di luar proses, misalnya melalui kabel dan bukan antar lapisan di dalam proses yang sama.