CLR Obyek Biasa vs Obyek Transfer Data

POCO = Obyek Old CLR (atau lebih baik: Class)

DTO = Objek Transfer Data

Dalam posting ini ada perbedaan, tetapi terus terang sebagian besar blog yang saya baca menggambarkan POCO dalam cara DTO didefinisikan: DTO adalah wadah data sederhana yang digunakan untuk memindahkan data antara lapisan aplikasi.

Apakah POCO dan DTO adalah hal yang sama?

POCO mengikuti aturan OOP. Seharusnya (tetapi tidak harus) memiliki keadaan dan perilaku. POCO berasal dari POJO, diciptakan oleh Martin Fowler [ anekdot di sini ]. Dia menggunakan istilah POJO sebagai cara untuk membuatnya lebih seksi untuk menolak kerangka implementasi EJB yang berat. POCO harus digunakan dalam konteks yang sama di .Net. Jangan biarkan kerangka kerja mendikte desain objek Anda.

Satu-satunya tujuan DTO adalah untuk mentransfer status, dan seharusnya tidak memiliki perilaku. Lihat penjelasan Martin Fowler tentang DTO untuk contoh penggunaan pola ini.

Inilah perbedaannya: POCO menjelaskan pendekatan pemrograman ( pemrograman berorientasi objek kuno yang baik), di mana DTO adalah pola yang digunakan untuk "mentransfer data" menggunakan objek.

Meskipun Anda dapat memperlakukan POCO seperti DTO, Anda berisiko membuat model domain anemia jika Anda melakukannya. Selain itu, ada ketidakcocokan dalam struktur, karena DTO harus dirancang untuk mentransfer data, bukan untuk mewakili struktur sebenarnya dari domain bisnis. Hasil dari ini adalah bahwa DTO cenderung lebih datar daripada domain Anda yang sebenarnya.

Dalam domain dengan kompleksitas yang masuk akal, Anda hampir selalu lebih baik membuat POCO domain terpisah dan menerjemahkannya ke DTO. DDD (desain berbasis domain) mendefinisikan lapisan anti-korupsi (tautan lain di sini , tetapi hal terbaik yang harus dilakukan adalah membeli buku ), yang merupakan struktur yang baik yang membuat pemisahan jelas.

Itu mungkin berlebihan bagi saya untuk berkontribusi karena saya sudah menyatakan posisi saya di artikel blog saya, tetapi paragraf terakhir dari artikel itu meringkaskan:

Jadi, sebagai kesimpulan, belajarlah untuk mencintai POCO, dan pastikan Anda tidak menyebarkan informasi yang salah tentang hal itu sama dengan DTO. DTO adalah wadah data sederhana yang digunakan untuk memindahkan data di antara lapisan aplikasi. POCO adalah objek bisnis penuh dengan satu persyaratan bahwa mereka Ketidaktahuan (tidak ada metode mendapatkan atau menyimpan). Terakhir, jika Anda belum membaca buku Jimmy Nilsson, ambil dari tumpukan universitas setempat. Ini memiliki contoh dalam C # dan itu adalah bacaan yang bagus.

BTW, Patrick Saya membaca POCO sebagai artikel Gaya Hidup, dan saya sepenuhnya setuju, itu adalah artikel yang fantastis. Ini sebenarnya bagian dari buku Jimmy Nilsson yang saya rekomendasikan. Saya tidak tahu itu tersedia online. Bukunya benar-benar adalah sumber informasi terbaik yang saya temukan di POCO / DTO / Repository / dan praktik pengembangan DDD lainnya.

POCO hanyalah sebuah objek yang tidak bergantung pada kerangka eksternal. Itu adalah polos.

Apakah POCO memiliki perilaku atau tidak, itu tidak penting.

DTO dapat berupa POCO sebagaimana objek domain (yang biasanya kaya akan perilaku).

Biasanya DTO lebih cenderung untuk mengambil dependensi pada kerangka kerja eksternal (misalnya atribut) untuk keperluan serialisasi karena biasanya mereka keluar pada batas sistem.

Dalam arsitektur gaya Onion yang khas (sering digunakan dalam pendekatan DDD luas) lapisan domain ditempatkan di tengah dan karenanya objek-objeknya tidak, pada titik ini, memiliki dependensi di luar lapisan itu.

Saya menulis artikel untuk topik itu: DTO vs Value Object vs POCO .

Pendeknya:

• DTO! = Nilai Objek
• DTO ⊂ POCO
• Nilai Objek ⊂ POCO

Saya pikir DTO bisa menjadi POCO. DTO lebih tentang penggunaan objek sementara POCO lebih dari gaya objek (dipisahkan dari konsep arsitektur).

Salah satu contoh di mana POCO adalah sesuatu yang berbeda dari DTO adalah ketika Anda berbicara tentang POCO di dalam model domain / model logika bisnis Anda, yang merupakan representasi OO yang bagus dari domain masalah Anda. Anda dapat menggunakan POCO di seluruh aplikasi, tetapi ini bisa memiliki beberapa efek samping yang tidak diinginkan seperti kebocoran pengetahuan. DTO misalnya digunakan dari Lapisan Layanan yang berkomunikasi dengan UI, DTO adalah representasi data yang datar, dan hanya digunakan untuk menyediakan data kepada UI, dan mengkomunikasikan perubahan kembali ke lapisan layanan. Lapisan layanan bertugas memetakan kedua cara DTO ke objek domain POCO.

Pembaruan Martin Fowler mengatakan bahwa pendekatan ini merupakan jalan yang berat untuk diambil, dan seharusnya hanya diambil jika ada ketidakcocokan yang signifikan antara lapisan domain dan antarmuka pengguna.

Kasus penggunaan utama untuk DTO adalah dalam mengembalikan data dari layanan web. Dalam hal ini, POCO dan DTO setara. Setiap perilaku dalam POCO akan dihapus ketika dikembalikan dari layanan web, jadi tidak masalah apakah itu memiliki perilaku atau tidak.

di sini adalah aturan umum: DTO == jahat dan indikator perangkat lunak yang direkayasa berlebihan. POCO == bagus. Pola 'perusahaan' telah menghancurkan otak banyak orang di dunia Java EE. tolong jangan ulangi kesalahan di .NET land.

Kelas DTO digunakan untuk membuat serial / deserialisasi data dari berbagai sumber. Ketika Anda ingin melakukan deserialisasi objek dari sumber, tidak peduli apa sumber eksternal itu: layanan, file, database dll. Anda mungkin hanya ingin menggunakan beberapa bagian dari itu tetapi Anda ingin cara mudah deserialize data ke suatu obyek. setelah itu Anda menyalin data itu ke XModel yang ingin Anda gunakan. Serializer adalah teknologi indah untuk memuat objek DTO. Mengapa? Anda hanya perlu satu fungsi untuk memuat (deserialize) objek.

TL; DR:

DTO menggambarkan pola transfer negara. POCO tidak menjelaskan apa pun. Ini cara lain untuk mengatakan "objek" di OOP. Itu berasal dari POJO (Jawa), diciptakan oleh Martin Fowler yang secara harfiah hanya menggambarkannya sebagai nama yang lebih menarik untuk 'objek' karena 'objek' tidak terlalu seksi.

DTO adalah pola objek yang digunakan untuk mentransfer keadaan di antara lapisan yang memprihatinkan. Mereka dapat memiliki perilaku (yaitu secara teknis bisa menjadi poco) selama perilaku itu tidak mengubah negara. Misalnya, mungkin ada metode yang membuat cerita bersambung.

POCO adalah objek polos, tetapi yang dimaksud dengan 'polos' adalah bahwa objek itu tidak istimewa. Ini hanya berarti itu adalah objek CLR tanpa pola tersirat padanya. Istilah umum. Itu tidak dibuat untuk bekerja dengan beberapa kerangka kerja lain. Jadi, jika POCO Anda memiliki [JsonProperty]atau dekorasi EF di seluruh propertinya, misalnya, maka saya berpendapat bahwa itu bukan POCO.

Berikut beberapa contoh berbagai jenis pola objek untuk dibandingkan:

• Lihat Model : digunakan untuk memodelkan data untuk tampilan. Biasanya memiliki anotasi data untuk membantu pengikatan dan validasi. Dalam MVVM, itu juga bertindak sebagai pengontrol. Ini lebih dari sekadar DTO
• Value Object : digunakan untuk merepresentasikan nilai
• Agregat Root : digunakan untuk mengelola negara dan invarian
• Penangan : digunakan untuk menanggapi suatu peristiwa / pesan
• Atribut : digunakan sebagai dekorasi untuk menangani masalah lintas sektoral
• Layanan : digunakan untuk melakukan tugas-tugas kompleks
• Controller : digunakan untuk mengontrol aliran permintaan dan respons
• Pabrik : digunakan untuk mengonfigurasi dan / atau merakit objek kompleks untuk digunakan ketika konstruktor tidak cukup baik. Juga digunakan untuk membuat keputusan tentang objek mana yang harus dibuat saat runtime.
• Repositori / DAO : digunakan untuk mengakses data

Ini semua hanyalah objek, tetapi perhatikan bahwa sebagian besar dari mereka umumnya terikat pada suatu pola. Jadi Anda bisa menyebutnya "objek" atau Anda bisa lebih spesifik tentang maksudnya dan menyebutnya dengan apa adanya. Ini juga mengapa kami memiliki pola desain; untuk menggambarkan konsep kompleks dalam beberapa karya. DTO adalah sebuah pola. Root agregat adalah sebuah pola, View Model adalah sebuah pola (mis. MVC & MVVM). POCO bukan sebuah pola.

POCO tidak menjelaskan suatu pola. Ini hanya cara berbeda untuk merujuk ke kelas / objek di OOP. Anggap saja sebagai konsep abstrak; mereka bisa merujuk pada apa saja. IMO, ada hubungan satu arah meskipun karena begitu suatu objek mencapai titik di mana ia hanya dapat melayani satu tujuan dengan bersih, itu bukan lagi POCO. Misalnya, setelah Anda menandai kelas Anda dengan dekorasi untuk membuatnya bekerja dengan beberapa kerangka kerja, itu bukan lagi POCO. Karena itu:

• DTO adalah POCO
• POCO bukan DTO
• Model Tampilan adalah POCO
• POCO bukan Model Tampilan

Poin dalam membuat perbedaan antara keduanya adalah tentang menjaga pola yang jelas dan konsisten dalam upaya untuk tidak melintasi masalah dan mengarah pada penggabungan yang ketat. Sebagai contoh jika Anda memiliki objek bisnis yang memiliki metode untuk bermutasi, tetapi juga dihiasi dengan dekorasi EF untuk disimpan ke SQL Server DAN JsonProperty sehingga dapat dikirim kembali melalui titik akhir API. Objek itu akan tidak toleran untuk berubah, dan kemungkinan akan dikotori dengan varian properti (misalnya UserId, UserPk, UserKey, UserGuid, di mana beberapa dari mereka ditandai untuk tidak disimpan ke DB dan yang lain ditandai untuk tidak diserialisasi ke JSON di titik akhir API).

Jadi, jika Anda memberi tahu saya bahwa ada sesuatu yang merupakan DTO, maka saya mungkin akan memastikan bahwa itu tidak pernah digunakan untuk hal lain selain mengubah keadaan. Jika Anda memberi tahu saya bahwa ada sesuatu yang merupakan model tampilan, maka saya mungkin akan memastikan itu tidak disimpan ke basis data. Jika Anda memberi tahu saya bahwa ada sesuatu yang merupakan Model Domain, maka saya mungkin akan memastikan tidak ada ketergantungan pada apa pun di luar domain. Tetapi jika Anda mengatakan kepada saya bahwa ada sesuatu yang disebut POCO, Anda tidak akan benar-benar memberi tahu saya sama sekali.

Jangan panggil mereka DTO. Mereka disebut Model .... Periode. Model tidak pernah memiliki perilaku. Saya tidak tahu siapa yang datang dengan DTO istilah bodoh ini, tetapi itu harus menjadi .NET yang bisa saya pikirkan. Pikirkan model tampilan di MVC, bendungan yang sama ** hal, model digunakan untuk mentransfer keadaan antara sisi server lapisan atau selama periode kawat, mereka semua model. Properti dengan data. Ini adalah model yang Anda lewati. Model, Model Model. Itu dia.

Saya berharap istilah bodoh DTO akan pergi dari kosakata kami.