Kerangka Entitas dan menghindari Model Domain Anemik

11

Dalam logika bisnis kami, kami terkadang menetapkan metode seperti ini:

User.ResetCourse(Course courseToReset)

Masalahnya adalah bahwa Pengguna dan Kursus adalah objek proxy Entity Framework. Ini berarti bahwa ketika kita menekan properti navigasi pada Pengguna atau Kursus itu dapat menyebabkan hit besar ke database karena objek-objek tersebut tidak dapat IQuery sehingga beralih melalui mereka secara normal.

Untuk mengatasi ini kami mengubah tanda tangan menjadi:

User.ResetCourse(MyDBContext db, Course courseToReset)

Ini berarti kita dapat secara langsung meminta basis data untuk membuat perubahan yang kita butuhkan secara efisien tetapi meneruskan konteks Database ke objek bisnis sepertinya sangat salah.

Kami kemudian bermigrasi ke pengguna lapisan layanan yang berarti kami memiliki sesuatu seperti:

CourseService.ResetForUser(Course courseToReset, User forUser)

Layanan ini memiliki referensi ke DBContext yang disuntikkan pada penciptaan tetapi sekarang objek bisnis kami hanya tas data tanpa perilaku (yaitu Model Domain Anemik).

Bagaimana kita bisa menghindari ini?

c# entity-framework domain-model business-logic

— Steve
sumber

11

Jenis suara seperti Anda baru saja mencapai kesadaran bahwa model kerangka entitas sebenarnya DTO, dan bukan model domain sama sekali. Apakah Anda benar-benar mencoba melakukan DDD? Jika tidak, mungkin tidak masalah.

— Mr Cochese

3

Layanan ADM plus adalah arsitektur yang baik untuk banyak hal

— Ewan

1

Yang bersangkutan: ADM bukan anti-pola, ini adalah desain SOLID .

— John Wu

2

@ JohnWu itu artikel yang sangat bias. Memang itu berisi versi "Strawman" dari model domain kaya, dengan memasukkan pola Rekaman Aktif dalam contoh kaya. Tentu saja, Rekaman Aktif tidak didukung dalam DDD dan secara umum adalah pilihan yang buruk untuk aplikasi yang kompleks.

— RibaldEddie

8

Masalahnya adalah, Anda menggunakan objek EF sebagai objek domain sejak awal. Objek EF adalah model data BUKAN model bisnis.

Anda perlu mendeklarasikan objek bisnis yang memberi Anda kebebasan untuk melakukan apa yang Anda butuhkan, dan kemudian mengambil dan menyimpannya dengan repositori. Repositori Anda akan memetakan entitas EF ke entitas bisnis Anda. Objek EF tidak boleh digunakan di luar repositori Anda.

— TheCatWhisperer
sumber

0

Anda mungkin dapat menghindarinya dengan melakukan sesuatu seperti:

CourseService.prepareForUserCourseReset(DBContext db);
User.reset();
Course.reset();
CourseService.completeUserCourseReset(DBContext db);

Atau sesuatu untuk efek itu, jika Anda mengetahui maksud saya. Kedengarannya seperti pendekatan yang Anda miliki dengan cara awal yang Anda gambarkan terkait kinerja , dan belum tentu terkait dengan struktur domain. Jadi sebenarnya Anda harus mempertimbangkan untuk memecahkan masalah kinerja di lapisan layanan tetapi dapat menjaga perilaku di domain. Akan sangat membantu untuk mengetahui apa artinya mengatur ulang Pengguna / Kursus dalam konteks ini juga jika Anda menginginkan jawaban yang lebih baik.

— RibaldEddie
sumber

-1

Secara tradisional, ini diselesaikan dengan menggunakan strategi pengambilan untuk setiap kasus penggunaan yang menginstruksikan Kerangka Entitas untuk segera memuat asosiasi yang diperlukan pada permintaan awal menggunakan IQueryable.Include ().

Udi Dahan menulis posting yang menggambarkan pendekatan umum, yang dapat disesuaikan dengan Kerangka Entitas.

http://udidahan.com/2007/09/16/fetching-strategy-nhibernate-implementation-available/

— pnschofield
sumber