Haruskah layanan selalu mengembalikan DTO, atau bisakah mereka juga mengembalikan model domain?


175

Saya sedang mendesain ulang aplikasi berskala besar, kami menggunakan arsitektur multi-layer berdasarkan DDD.

Kami memiliki MVC dengan lapisan data (implementasi repositori), lapisan domain (definisi model domain dan antarmuka - repositori, layanan, unit kerja), lapisan layanan (implementasi layanan). Sejauh ini, kami menggunakan model domain (sebagian besar entitas) di semua lapisan, dan kami menggunakan DTO hanya sebagai model tampilan (di controller, layanan mengembalikan model domain (s) dan controller membuat model tampilan, yang diteruskan ke tampilan).

Saya sudah membaca banyak artikel tentang menggunakan, tidak menggunakan, memetakan dan melewati DTO. Saya mengerti bahwa tidak ada jawaban pasti, tetapi saya tidak yakin apakah itu ok atau tidak mengembalikan model domain dari layanan ke pengontrol. Jika saya mengembalikan model domain, itu masih tidak pernah diteruskan ke tampilan, karena pengontrol selalu membuat model tampilan khusus tampilan - dalam hal ini, tampaknya sah. Di sisi lain, rasanya tidak benar ketika model domain meninggalkan lapisan bisnis (lapisan layanan). Terkadang layanan perlu mengembalikan objek data yang tidak didefinisikan dalam domain dan kemudian kami harus menambahkan objek baru ke domain yang tidak dipetakan, atau membuat objek POCO (ini jelek, karena beberapa layanan mengembalikan model domain, beberapa mengembalikan DTO secara efektif).

Pertanyaannya adalah - jika kita benar-benar menggunakan model tampilan, apakah boleh mengembalikan model domain sepenuhnya ke pengontrol, atau haruskah kita selalu menggunakan DTO untuk komunikasi dengan lapisan layanan? Jika demikian, apakah boleh menyesuaikan model domain berdasarkan kebutuhan layanan apa? (Sejujurnya saya tidak berpikir begitu, karena layanan harus menggunakan domain apa yang dimiliki.) Jika kita harus tetap berpegang teguh pada DTO, haruskah mereka didefinisikan di lapisan layanan? (Saya pikir begitu.) Kadang-kadang jelas bahwa kita harus menggunakan DTO (misalnya, ketika layanan melakukan banyak logika bisnis dan membuat objek baru), kadang-kadang jelas bahwa kita harus menggunakan model domain yang adil (misalnya, ketika layanan Keanggotaan mengembalikan Pengguna yang anemia ( s) - sepertinya tidak masuk akal untuk membuat DTO yang sama dengan model domain) - tapi saya lebih suka konsistensi dan praktik yang baik.

Domain Artikel vs DTO vs ViewModel - Bagaimana dan Kapan menggunakannya? (dan juga beberapa artikel lainnya) sangat mirip dengan masalah saya, tetapi tidak menjawab pertanyaan ini. Artikel Haruskah saya menerapkan DTO dalam pola repositori dengan EF? juga mirip, tetapi tidak berurusan dengan DDD.

Penafian: Saya tidak bermaksud menggunakan pola desain apa pun hanya karena ada dan mewah, di sisi lain, saya ingin menggunakan pola dan praktik desain yang baik juga karena membantu merancang aplikasi secara keseluruhan, membantu pemisahan masalah, bahkan untuk menggunakan pola tertentu tidak "diperlukan", setidaknya saat ini.

Seperti biasa, terima kasih.


28
Bagi mereka yang memilih penutupan - tolong beri tahukan mengapa Anda ingin menutup pertanyaan ini berdasarkan pendapat?
Robert Goldwein

20
@Ron "Tinjauan Kode adalah situs tanya jawab untuk berbagi kode dari proyek yang sedang Anda kerjakan untuk tinjauan sejawat." - Pertanyaan saya sama sekali bukan tentang kode, jadi itu akan menjadi topik di sana; SO: "Fokus pada pertanyaan tentang masalah aktual yang Anda hadapi. Sertakan detail tentang apa yang telah Anda coba dan apa yang Anda coba lakukan." - Saya memiliki masalah ahli khusus, yang saya coba pecahkan. Bisakah Anda lebih spesifik apa yang salah dengan pertanyaan ini, karena banyak pertanyaan di sini tentang arsitektur dan pertanyaan seperti itu tampaknya ok, jadi saya dapat menghindari kesalahpahaman lebih lanjut?
Robert Goldwein

7
Terima kasih telah mengajukan pertanyaan itu. Anda melakukan kebaikan untuk saya, dan membuat hidup saya lebih sederhana dan bahagia, terima kasih.
Loa

9
@RobertGoldwein, jangan pedulikan SO Close Mafia, pertanyaan Anda sah.
hyankov

3
Terima kasih banyak telah mengajukan pertanyaan ini
salman

Jawaban:


177

rasanya tidak benar ketika model domain meninggalkan lapisan bisnis (lapisan layanan)

Membuat Anda merasa seperti menarik keluar nyali bukan? Menurut Martin Fowler: Lapisan Layanan menentukan batas aplikasi, itu merangkum domain. Dengan kata lain itu melindungi domain.

Terkadang layanan perlu mengembalikan objek data yang tidak didefinisikan dalam domain

Bisakah Anda memberikan contoh objek data ini?

Jika kita harus berpegang teguh pada DTO, haruskah mereka didefinisikan di lapisan layanan?

Ya, karena responsnya adalah bagian dari lapisan layanan Anda. Jika itu didefinisikan "di tempat lain" maka lapisan layanan perlu merujuk bahwa "di tempat lain", menambahkan lapisan baru ke lasagna Anda.

apakah boleh mengembalikan model domain ke pengontrol, atau haruskah kita selalu menggunakan DTO untuk komunikasi dengan lapisan layanan?

DTO adalah objek respons / permintaan, masuk akal jika Anda menggunakannya untuk komunikasi. Jika Anda menggunakan model domain di lapisan presentasi Anda (MVC-Controllers / View, WebForms, ConsoleApp), maka lapisan presentasi digabungkan erat ke domain Anda, setiap perubahan dalam domain mengharuskan Anda untuk mengubah pengontrol Anda.

sepertinya tidak masuk akal untuk membuat DTO yang sama dengan model domain)

Ini adalah salah satu kelemahan DTO di mata baru. Saat ini, Anda sedang berpikir duplikasi kode , tetapi ketika proyek Anda diperluas maka akan jauh lebih masuk akal, khususnya di lingkungan tim di mana tim yang berbeda ditugaskan ke lapisan yang berbeda.

DTO mungkin menambah kompleksitas tambahan untuk aplikasi Anda, tetapi begitu juga layer Anda. DTO adalah fitur mahal dari sistem Anda, mereka tidak datang gratis.

Mengapa menggunakan DTO

Artikel ini memberikan keuntungan dan kerugian menggunakan DTO, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html

Ringkasan sebagai berikut:

Kapan Harus Digunakan

  • Untuk proyek besar.
  • Umur proyek adalah 10 tahun ke atas.
  • Strategis, aplikasi misi kritis.
  • Tim besar (lebih dari 5)
  • Pengembang didistribusikan secara geografis.
  • Domain dan presentasi berbeda.
  • Mengurangi pertukaran data overhead (tujuan awal DTO)

Kapan tidak digunakan

  • Proyek kecil hingga menengah (maks 5 anggota)
  • Umur proyek sekitar 2 tahun atau lebih.
  • Tidak ada tim terpisah untuk GUI, backend, dll.

Argumen Melawan DTO

Argumen dengan DTO

  • Tanpa DTO, presentasi dan domain sangat erat. (Ini ok untuk proyek kecil.)
  • Stabilitas antarmuka / API
  • Dapat memberikan pengoptimalan untuk lapisan presentasi dengan mengembalikan DTO yang hanya berisi atribut yang benar-benar diperlukan. Dengan menggunakan proyeksi linq , Anda tidak perlu menarik seluruh entitas.
  • Untuk mengurangi biaya pengembangan, gunakan alat penghasil kode

3
Hai, terima kasih atas jawaban Anda, ini ringkasan yang bagus, dan juga terima kasih atas tautannya. Kalimat saya "Kadang-kadang layanan perlu mengembalikan objek data yang tidak didefinisikan dalam domain" salah dipilih, artinya layanan menggabungkan beberapa DO dari satu repositori (misalnya atribut) dan menghasilkan satu POCO sebagai komposisi atribut ini (berdasarkan pada logika bisnis). Sekali lagi, terima kasih atas jawaban yang sangat bagus.
Robert Goldwein

1
Pertimbangan kinerja penting adalah bagaimana model-model domain atau DTO dikembalikan dari layanan Anda. Dengan EF, jika Anda mewujudkan kueri untuk mengembalikan koleksi model domain yang konkret (dengan .ToArray () atau ToList (), misalnya), Anda memilih semua kolom untuk mengisi objek yang direalisasikan. Jika Anda memproyeksikan DTO sebagai gantinya, EF cukup pintar untuk memilih hanya kolom yang diperlukan untuk mengisi DTO Anda, yang dapat secara signifikan mengurangi data untuk ditransfer dalam beberapa kasus.
dengus

10
Anda dapat memetakan objek Anda 'dengan tangan'. Saya tahu, hal-hal yang membosankan, tetapi membutuhkan 2-3 menit per model dan selalu ada kemungkinan untuk membawa banyak masalah ketika Anda menggunakan banyak refleksi (AutoMapper dll.)
Razvan Dumitru

1
terima kasih telah menjawab begitu sederhana dan dengan konten seperti itu. Anda melakukan kebaikan untuk saya, dan membuat hidup saya lebih sederhana dan bahagia, terima kasih.
Loa

1
Kami memiliki proyek 10 juta dibatalkan karena itu memperlambat ... Mengapa itu lambat? Mentransfer objek DTO ke semua tempat menggunakan refelection. Hati-hati. Automapper juga menggunakan refleksi.
Ray Tanpa Cinta

11

Tampaknya aplikasi Anda cukup besar dan kompleks karena Anda telah memutuskan untuk melakukan pendekatan DDD. Jangan kembalikan entitas poco Anda atau yang disebut entitas domain dan objek nilai di lapisan layanan Anda. Jika Anda ingin melakukan ini, hapus layer layanan Anda karena Anda tidak membutuhkannya lagi! Lihat Model atau objek transfer Data harus hidup di lapisan Layanan karena mereka harus memetakan ke anggota model domain dan sebaliknya. Jadi mengapa Anda perlu memiliki DTO? Dalam aplikasi yang kompleks dengan banyak skenario Anda harus memisahkan keprihatinan domain dan tampilan presentasi Anda, model domain dapat dibagi menjadi beberapa DTO dan juga beberapa model Domain dapat diciutkan menjadi DTO. Jadi lebih baik untuk membuat DTO Anda dalam arsitektur berlapis bahkan itu akan sama dengan model Anda.

Haruskah kita selalu menggunakan DTO untuk komunikasi dengan lapisan layanan? Ya, Anda harus mengembalikan DTO oleh lapisan layanan Anda karena Anda telah berbicara dengan repositori Anda di lapisan layanan dengan anggota model domain dan memetakannya ke DTO dan kembali ke pengontrol MVC dan sebaliknya.

Apakah boleh untuk menyesuaikan model domain berdasarkan kebutuhan layanan apa? Sebuah layanan hanya berbicara dengan repositori dan metode domain serta layanan domain, Anda harus menyelesaikan bisnis di domain Anda berdasarkan kebutuhan Anda dan itu bukan tugas layanan untuk memberi tahu domain apa yang dibutuhkan.

Jika kita harus berpegang teguh pada DTO, haruskah mereka didefinisikan di lapisan layanan? Ya, coba miliki DTO atau ViewModel hanya dalam layanan nanti karena mereka harus dipetakan ke anggota domain di lapisan layanan dan itu bukan ide yang baik untuk menempatkan DTO di pengontrol aplikasi Anda (coba gunakan pola Respons Permintaan di lapisan Layanan Anda), tepuk tangan !


1
maaf soal itu! Anda dapat melihatnya di sini ehsanghanbari.com/blog/Post/7/…
Ehsan

10

Dalam pengalaman saya, Anda harus melakukan apa yang praktis. "Desain terbaik adalah desain paling sederhana yang berfungsi" - Einstein. Dengan itu adalah pikiran ...

jika kita benar-benar menggunakan model tampilan, apakah boleh mengembalikan model domain sepenuhnya ke pengontrol, atau haruskah kita selalu menggunakan DTO untuk komunikasi dengan lapisan layanan?

Benar-benar tidak apa-apa! Jika Anda memiliki Entitas Domain, DTO, dan Lihat Model, kemudian sertakan tabel database Anda memiliki semua bidang dalam aplikasi diulang di 4 tempat. Saya telah bekerja pada proyek besar di mana Entitas Domain dan Model Tampilan bekerja dengan baik. Satu-satunya pengecualian untuk ini adalah jika aplikasi didistribusikan dan lapisan layanan berada di server lain dalam hal ini DTO diminta untuk mengirim melalui kawat untuk alasan serialisasi.

Jika demikian, apakah boleh menyesuaikan model domain berdasarkan kebutuhan layanan apa? (Terus terang saya tidak berpikir begitu, karena layanan harus mengkonsumsi domain apa yang dimiliki.)

Secara umum saya setuju dan mengatakan tidak karena model Domain biasanya merupakan cerminan dari logika bisnis dan biasanya tidak dibentuk oleh konsumen logika itu.

Jika kita harus berpegang teguh pada DTO, haruskah mereka didefinisikan di lapisan layanan? (Aku pikir begitu.)

Jika Anda memutuskan untuk menggunakannya, saya setuju dan mengatakan ya, lapisan Layanan adalah tempat yang sempurna karena mengembalikan DTO pada akhir hari.

Semoga berhasil!


8

Saya terlambat ke pesta ini, tetapi ini adalah pertanyaan yang umum, dan penting, sehingga saya merasa harus menanggapinya.

Yang dimaksud dengan "layanan", maksud Anda "Lapisan Aplikasi" yang dijelaskan oleh Evan dalam buku biru ? Saya akan menganggap Anda melakukannya, dalam hal ini jawabannya adalah bahwa mereka tidak boleh mengembalikan DTO. Saya sarankan membaca bab 4 dalam buku biru, berjudul "Isolating the Domain".

Dalam bab itu, Evans mengatakan hal berikut tentang lapisan:

Partisi program yang kompleks menjadi beberapa lapisan. Kembangkan desain dalam setiap lapisan yang kohesif dan itu hanya bergantung pada lapisan di bawah ini.

Ada alasan bagus untuk ini. Jika Anda menggunakan konsep urutan parsial sebagai ukuran kompleksitas perangkat lunak maka memiliki lapisan yang bergantung pada lapisan di atasnya akan menambah kompleksitas, yang menurunkan kemampuan pemeliharaan.

Menerapkan ini untuk pertanyaan Anda, DTO benar-benar merupakan adaptor yang menjadi perhatian lapisan User Interface / Presentation. Ingatlah bahwa komunikasi jarak jauh / lintas-proses adalah persis tujuan DTO (perlu dicatat bahwa dalam pos itu Fowler juga berpendapat bahwa DTO menjadi bagian dari lapisan layanan, meskipun ia tidak harus berbicara bahasa DDD).

Jika lapisan aplikasi Anda bergantung pada DTO tersebut, itu tergantung pada lapisan di atasnya dan kompleksitas Anda meningkat. Saya dapat menjamin bahwa ini akan meningkatkan kesulitan memelihara perangkat lunak Anda.

Misalnya, bagaimana jika sistem Anda berinteraksi dengan beberapa sistem atau tipe klien lain, masing-masing membutuhkan DTO sendiri? Bagaimana Anda tahu metode DTO mana yang harus dikembalikan oleh layanan aplikasi Anda? Bagaimana Anda bahkan memecahkan masalah itu jika bahasa pilihan Anda tidak memungkinkan kelebihan metode (metode layanan, dalam hal ini) berdasarkan jenis pengembalian? Dan bahkan jika Anda mencari cara, mengapa melanggar Layer Aplikasi Anda untuk mendukung masalah lapisan Presentasi?

Secara praktis, ini adalah langkah menurun yang akan berakhir dengan arsitektur spageti. Saya telah melihat devolusi semacam ini dan hasilnya dalam pengalaman saya sendiri.

Di mana saya saat ini bekerja, layanan di Layer Aplikasi kami mengembalikan objek domain. Kami tidak menganggap ini masalah karena lapisan Antarmuka (yaitu UI / Presentasi) tergantung pada lapisan Domain, yang berada di bawahnya. Juga, ketergantungan ini diminimalkan ke jenis ketergantungan "hanya referensi" karena:

a) Lapisan Antarmuka hanya dapat mengakses objek-objek Domain ini sebagai nilai kembali hanya-baca yang diperoleh melalui panggilan ke lapisan Aplikasi

b) metode pada layanan dalam Lapisan Aplikasi menerima sebagai input hanya input "mentah" (nilai data) atau parameter objek (untuk mengurangi jumlah parameter bila perlu) didefinisikan dalam lapisan itu. Secara khusus, layanan aplikasi tidak pernah menerima objek Domain sebagai input.

Layer Interface menggunakan teknik pemetaan yang didefinisikan dalam Layer Interface itu sendiri untuk memetakan dari objek Domain ke DTO. Sekali lagi, ini membuat DTO fokus pada menjadi adaptor yang dikendalikan oleh Layer Interface.


1
Pertanyaan cepat. Saya saat ini berputar pada apa yang harus kembali dari lapisan aplikasi saya. Mengembalikan entitas domain dari lapisan aplikasi terasa salah. Apakah saya benar-benar ingin membocorkan domain ke "luar"? Jadi saya merenungkan DTO dari lapisan aplikasi. Tapi itu menambah model lain. Dalam respons Anda, Anda mengatakan Anda mengembalikan model Domain sebagai "nilai balik hanya baca". Bagaimana kamu melakukannya? Yaitu, bagaimana Anda membuat mereka hanya membaca?
Michael Andrews

Saya pikir saya hanya akan mengadopsi posisi Anda. Layanan aplikasi mengembalikan model Domain. Lapisan adaptor port (REST, presentasi, dll.) Kemudian menerjemahkannya ke dalam model mereka sendiri (lihat model atau representasi). Menambahkan model DTO antara aplikasi dan adaptor port tampaknya berlebihan. Mengembalikan model domain masih mematuhi DIP, dan logika domain tetap berada di dalam konteks terikat (belum tentu di dalam batas aplikasi. Tapi itu sepertinya kompromi yang bagus).
Michael Andrews

@MichaelAndrews, senang mendengar bahwa jawaban saya membantu. Re: pertanyaan Anda tentang objek yang dikembalikan menjadi hanya-baca, objek itu sendiri tidak benar-benar hanya-baca (yaitu tidak dapat diubah). Yang saya maksudkan adalah itu tidak terjadi dalam praktik (setidaknya dalam pengalaman saya). Untuk memperbarui objek domain, Layer Interface harus a) mereferensikan repositori objek domain, atau b) memanggil kembali ke dalam Lapisan Aplikasi untuk memperbarui objek yang baru saja diterima. Salah satu dari ini adalah pelanggaran yang jelas terhadap praktik DDD yang baik sehingga saya menemukan mereka harus ditegakkan sendiri. Jangan ragu untuk memilih jawaban jika Anda mau.
BitMask777

Jawaban ini sangat intuitif bagi saya karena beberapa alasan. Pertama, kita dapat menggunakan kembali Application Layer yang sama untuk beberapa UI (API, Controllers) dan masing-masing dapat mengubah model sesuai keinginan. Kedua, jika kita mengubah model-ke-DTO di App. Layer, itu berarti DTO didefinisikan di App. Layer, yang pada gilirannya berarti DTO sekarang menjadi bagian dari Konteks Terikat kami (belum tentu Domain!) - ini terasa salah.
Robotron

1
Saya baru saja akan menanyakan kepada Anda pertanyaan lanjutan dan kemudian melihat Anda sudah menjawabnya: "layanan aplikasi tidak pernah menerima objek Domain sebagai masukan". Saya akan memberi +1 lagi jika saya bisa.
Robotron

5

Terlambat ke pesta, tapi saya menghadapi jenis arsitektur yang sama persis dan saya condong ke "hanya DTO dari layanan". Ini terutama karena saya telah memutuskan untuk hanya menggunakan objek / agregat domain untuk mempertahankan validitas dalam objek, sehingga hanya ketika memperbarui, membuat, atau menghapus. Saat kami meminta data, kami hanya menggunakan EF sebagai repositori dan memetakan hasilnya ke DTO. Ini membuat kami bebas untuk mengoptimalkan kueri baca dan tidak menyesuaikannya dengan objek bisnis, sering menggunakan fungsi basis data karena cepat.

Setiap metode layanan mendefinisikan kontraknya sendiri dan karenanya lebih mudah untuk mempertahankannya dari waktu ke waktu. Saya harap.


1
Setelah bertahun-tahun kami sampai pada kesimpulan yang sama, tepatnya untuk alasan yang Anda sebutkan di sini.
Robert Goldwein

@RobertGoldwein Bagus sekali! Saya merasa lebih percaya diri dalam keputusan saya sekarang. :-)
Niklas Wulff

@NiklasWulff: jadi, Dto yang dimaksud sekarang adalah bagian dari kontrak Lapisan Aplikasi, yaitu bagian dari inti / domain. Bagaimana dengan tipe pengembalian API Web ? Apakah Anda mengekspos Dtos yang disebutkan dalam jawaban Anda atau apakah Anda telah mendedikasikan Model Tampilan yang ditentukan dalam lapisan Web API? Atau dengan kata lain: apakah Anda memetakan Dtos ke Lihat Model?
Robotron

1
@Robotron Kami tidak memiliki API Web, kami menggunakan MVC. Jadi ya, kami memetakan dto: s ke model tampilan yang berbeda. Seringkali model tampilan berisi banyak hal lain untuk menampilkan halaman web, sehingga data dari dto: s hanya merupakan bagian dari model tampilan
Niklas Wulff

4

Sejauh ini, kami menggunakan model domain (sebagian besar entitas) di semua lapisan, dan kami menggunakan DTO hanya sebagai model tampilan (dalam pengontrol, model domain pengembalian layanan) dan pengontrol membuat model tampilan, yang diteruskan ke tampilan).

Karena Model Domain menyediakan terminologi ( Bahasa yang Tidak Dapat Ditebak ) untuk seluruh aplikasi Anda, lebih baik menggunakan Model Domain secara luas.

Satu-satunya alasan untuk menggunakan ViewModels / DTO adalah implementasi pola MVC dalam aplikasi Anda untuk memisahkan View(segala jenis lapisan presentasi) dan Model(Model Domain). Dalam hal ini, presentasi dan model domain Anda secara longgar digabungkan.

Kadang-kadang layanan perlu mengembalikan objek data yang tidak didefinisikan dalam domain dan kemudian kita harus menambahkan objek baru ke domain yang tidak dipetakan, atau membuat objek POCO (ini jelek, karena beberapa layanan mengembalikan model domain, beberapa mengembalikan DTO secara efektif).

Saya berasumsi bahwa Anda berbicara tentang layanan Logika Aplikasi / Bisnis / Domain.

Saya sarankan Anda mengembalikan entitas domain saat Anda bisa. Jika diperlukan untuk mengembalikan informasi tambahan, dapat diterima untuk mengembalikan DTO yang memiliki beberapa entitas domain.

Kadang-kadang, orang-orang yang menggunakan kerangka kerja bagian 3, yang menghasilkan proxy atas entitas domain, menghadapi kesulitan mengekspos entitas domain dari layanan mereka, tetapi itu hanya masalah penggunaan yang salah.

Pertanyaannya adalah - jika kita benar-benar menggunakan model tampilan, apakah boleh mengembalikan model domain sepenuhnya ke pengontrol, atau haruskah kita selalu menggunakan DTO untuk komunikasi dengan lapisan layanan?

Saya akan mengatakan itu cukup untuk mengembalikan entitas domain dalam 99,9% kasus.

Untuk menyederhanakan pembuatan DTO dan memetakan entitas domain Anda ke dalamnya, Anda dapat menggunakan AutoMapper .


4

Jika Anda mengembalikan bagian dari model domain Anda, itu menjadi bagian dari kontrak. Kontrak sulit untuk diubah, karena hal-hal di luar konteks Anda bergantung padanya. Dengan demikian, Anda akan membuat bagian dari model domain Anda sulit diubah.

Aspek yang sangat penting dari model domain adalah mudah diubah. Ini membuat kami fleksibel terhadap persyaratan perubahan domain.


2

Saya sarankan menganalisis dua pertanyaan ini:

  1. Apakah lapisan atas Anda (yaitu melihat & melihat model / pengontrol) mengonsumsi data dengan cara yang berbeda dari apa yang ditampilkan lapisan domain? Jika ada banyak pemetaan yang dilakukan atau bahkan logika yang terlibat saya akan menyarankan mengunjungi kembali desain Anda: mungkin harus lebih dekat dengan bagaimana data sebenarnya digunakan.

  2. Seberapa besar kemungkinan Anda mengubah lapisan atas Anda? (mis. menukar ASP.NET untuk WPF). Jika ini sangat berbeda dan arsitektur Anda tidak terlalu kompleks, Anda mungkin lebih baik mengekspos entitas domain sebanyak yang Anda bisa.

Saya khawatir itu adalah topik yang cukup luas dan benar-benar turun ke seberapa rumit sistem Anda dan persyaratannya.


Dalam kasus kami, lapisan atas pasti tidak akan berubah. Dalam beberapa kasus, layanan mengembalikan objek POCO yang cukup unik (dibangun dari lebih banyak domain - misalnya, pengguna dan file yang dimilikinya), dalam beberapa kasus layanan mengembalikan hanya model domain - misalnya, hasil "FindUserByEmail () harus mengembalikan model domain Pengguna - dan inilah kekhawatiran saya, kadang-kadang layanan kami mengembalikan model domain, kadang-kadang DTO baru - dan saya tidak suka ketidakkonsistenan ini, saya membaca artikel sebanyak mungkin dan mayoritas tampaknya setuju bahwa meskipun pemetaan Model Domain <-> DTO adalah 1: 1, model domain tidak boleh meninggalkan lapisan layanan - jadi saya terkoyak
Robert Goldwein

Dalam skenario seperti itu dan asalkan Anda dapat menanggung upaya pengembangan ekstra saya juga akan pergi dengan pemetaan sehingga layering Anda lebih konsisten.
jnovo

1

Dalam pengalaman saya, kecuali Anda menggunakan pola OO UI (seperti objek telanjang), mengekspos objek domain ke UI adalah ide yang buruk. Ini karena seiring pertumbuhan aplikasi, kebutuhan dari UI berubah dan memaksa objek Anda untuk mengakomodasi perubahan tersebut. Anda akhirnya melayani 2 master: UI dan DOMAIN yang merupakan pengalaman yang sangat menyakitkan. Percayalah, Anda tidak ingin berada di sana. Model UI memiliki fungsi berkomunikasi dengan pengguna, model DOMAIN untuk memegang aturan bisnis dan model ketekunan berkaitan dengan menyimpan data secara efektif. Mereka semua menangani berbagai kebutuhan aplikasi. Saya di tengah menulis posting blog tentang ini, akan menambahkannya ketika sudah selesai.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.