Banyak yang telah dibicarakan tentang Entity Framework versi pertama di web (juga di stackoverflow) dan jelas bahwa itu bukan pilihan yang baik ketika kami sudah memiliki alternatif yang lebih baik seperti NHibernate. Tetapi saya tidak dapat menemukan perbandingan yang baik antara Entity Framework 4 dan NHibernate. Kita dapat mengatakan bahwa hari ini NHibernate adalah pemimpin di antara semua ORM .NET, tetapi dapatkah kita mengharapkan Entity Framework 4 menggantikan NHibernate dari posisi ini. Saya pikir jika Microsoft telah benar-benar memasukkan fitur yang sangat bagus ke dalam EF4, ini dapat memberikan persaingan yang baik kepada NHibernate karena memiliki integrasi Visual Studio, lebih mudah untuk bekerja dengan dan preferensi selalu diberikan pada produk MS di sebagian besar toko.
Entity Framework 4 vs NHibernate [ditutup]
Jawaban:
EF4 memiliki jawaban out-the-box berkenaan dengan pengembangan n-tier, dalam "entitas pelacakan mandiri". Tidak ada yang merilis kode sebanding untuk NHib.
NHib memiliki banyak fitur yang belum disebutkan sebagai bagian dari EF4. Ini termasuk integrasi cache tingkat kedua. Ini juga memiliki fleksibilitas yang lebih besar dalam pemetaan warisan, integrasi yang lebih baik dengan procs tersimpan / fungsi database / SQL kustom / pemicu, dukungan untuk properti rumus, dan sebagainya. IMO itu pada dasarnya hanya lebih dewasa sebagai ORM.
Pembaruan: Saya belum pernah menggunakan Entity Framework sejak versi 4.0, jadi jawaban saya mungkin sudah ketinggalan zaman. Saya masih menggunakan NH atau ADO .NET murni dalam proyek saya. Dan saya bahkan tidak ingin melihat apa yang baru di EF sejak 4.0, karena NH bekerja dengan sempurna.
Sebenarnya cukup mudah untuk membandingkan keduanya bila Anda telah menggunakan keduanya. Ada beberapa batasan serius dengan EF4, saya dapat menyebutkan beberapa yang saya temui sendiri:
Masalah EF4:
- Eager Memuat dan membentuk hasil : EF4 eager loading system (Include ("Path")) menghasilkan SQL yang tidak tepat, dengan perulangan JOIN, yang akan mengeksekusi ribuan (tidak secara harfiah) waktu lebih lambat untuk hubungan banyak-ke-banyak kemudian SQL yang ditulis tangan (itu efektif tidak dapat digunakan).
- Materializer tidak dapat mewujudkan entitas terkait : Jika Anda merasa dapat mengatasi masalah sebelumnya dengan memberikan kueri SQL Anda sendiri, Anda salah. EF4 tidak dapat mewujudkan (memetakan) entitas terkait dari kueri JOIN SQL, ia hanya dapat memuat data dari satu tabel (Jadi jika Anda memiliki Order.Product, SELECT * FROM order LEFT JOIN Produk hanya akan menginisialisasi objek Order, Produk akan tetap null, mengira semua data yang diperlukan diambil dalam kueri untuk memulainya). Ini dapat diatasi dengan menggunakan add-on komunitas EFExtensions, tetapi kode yang harus Anda tulis untuk ini benar-benar jelek (saya mencoba).
Entitas Pelacakan Diri: Banyak yang mengatakan bahwa entitas pelacakan mandiri itu keren untuk pengembangan tingkat-N termasuk jawaban teratas di utas ini. Pikir saya bahkan belum mencobanya, saya dapat mengatakan bahwa mereka tidak. Setiap input dapat dipalsukan, Anda tidak bisa begitu saja mengambil perubahan yang dikirim pengguna kepada Anda dan menerapkannya ke basis data, mengapa tidak memberikan data langsung kepada pengguna akses dasar kemudian? Dengan cara apa pun Anda harus memuat data yang akan diubah pengguna dari DB, periksa apakah data itu ada | tidak ada, lakukan pemeriksaan izin, dll. Anda tidak dapat mempercayai pengguna tentang status entitas yang dia kirim ke server, Anda tetap akan melakukannya harus memuat entitas ini dari DB dan menentukan statusnya dan hal-hal lain, jadi informasi ini tidak berguna, seperti halnya entitas Pelacakan Mandiri kecuali jika Anda melakukan sistem n-tier terpercaya pribadi untuk penggunaan internal, dalam hal ini mungkin Anda dapat memberikan Akses DB.
Logging, Acara, mengintegrasikan logika bisnis: EF4 seperti kotak hitam, melakukan sesuatu dan Anda tidak tahu apa fungsinya. Hanya ada satu peristiwa OnSavingChanges di mana Anda dapat meletakkan beberapa logika bisnis yang perlu Anda jalankan sebelum sesuatu terjadi dengan DB, dan jika Anda perlu menerapkan beberapa perubahan pada objek bisnis sebelum sesuatu terjadi, Anda harus menggali di ObjectStateManager, dan ini benar-benar jelek , kode bisa menjadi sangat besar. Jika Anda misalnya menggunakan pola Repositori dan apa yang harus diberitahukan tentang perubahan yang dilakukan pada DB dengan cara objek yang bersih, Anda akan kesulitan melakukan ini dengan EF.
Ekstensibilitas: Semua kode EF bersifat pribadi dan internal, jika Anda tidak menyukai sesuatu (dan Anda tidak akan menyukai BANYAK jika Anda serius tentang penggunaan EF), tidak mungkin Anda mengubahnya dengan cara yang mudah, Sebenarnya saya yakin lebih mudah menulis ORM Anda sendiri dari awal (saya lakukan) lalu buat EF berfungsi sesuai kebutuhan Anda. Sebagai contoh, lihat sumber EFExtensions, ini didasarkan pada metode ekstensi, dan "peretasan" yang berbeda untuk membuat EF sedikit lebih dapat digunakan, dan kodenya cukup jelek (dan bukan kesalahan penulis, ketika semua di EF bersifat pribadi, ini adalah satu-satunya cara untuk memperpanjangnya).
Saya dapat terus menulis hal-hal buruk tentang EF dan betapa menyakitkan bagi saya bekerja dengannya selama 20 halaman, dan mungkin saya akan melakukannya.
Bagaimana dengan NHibernate? Levelnya benar-benar berbeda, seperti membandingkan PHP dengan C #, EF4 seperti di Zaman Batu, EF 10 tahun lebih lambat dari NHibernate dalam proses pengembangan, dan kenyataannya, Hibernate dimulai pada tahun 2001. Jika Anda memiliki waktu luang untuk mempelajari dan mengaktifkan Nhibernate, lakukanlah.
Ini masalahnya. NHibernate dan Entity Framework sebenarnya untuk dua audiens yang berbeda, menurut saya. NHibernate akan menjadi pilihan saya dalam membangun sistem dengan pemetaan, rumus, dan batasan yang kompleks (pada dasarnya perusahaan apa pun). Jika saya ingin memulai dengan akses data sederhana, saya akan menggunakan Entity Framework atau LINQ-to-SQL. NHibernate tidak memiliki pengalaman "seret dan lepas" yang jelas seperti EF. Keduanya memiliki kelebihan dan kekurangan. Membandingkan mereka apel-dengan-apel, terus terang, tidak membawa Anda kemana-mana.
Jika Anda berpikir Anda mungkin ingin menjalankan kode Anda di Mono, NHibernate mungkin adalah pilihan yang lebih baik tidak peduli apa yang dikatakan daftar periksa fitur ...
Sunting, 13/8/2012:
Kerangka Kerja Entitas telah bersumber terbuka, dan sekarang disertakan dalam Mono mulai 2.11.3. Jawaban ini sekarang sudah usang dan tidak boleh diandalkan.
http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx
Menurut saya, EF4.0 telah berkembang pesat sejak 1.0 dan mengejar Nhibernate dalam fungsinya, tetapi belum semuanya.
Bagaimanapun itu adalah Microsoft, di luar kotak, dan melakukan 100% dari apa yang 95% perlu dilakukan oleh aplikasi. Namun, NHibernate telah melakukan hal yang sama selama bertahun-tahun. Ayo versi 5.0 atau 6.0 mungkin mengejar, atau bahkan melampaui NHibernate.
Inilah saran saya - jika Anda punya waktu untuk mempelajari keduanya, lakukanlah. Ada beberapa alasan untuk memilih salah satu dari yang lainnya. Jika Anda menulis kode untuk perusahaan, adalah realistis untuk mengharapkan karyawan cakap yang akan terbiasa dengan EF, seperti yang ada di semua buku dan apa yang dipelajari anak-anak di perguruan tinggi. Jika EF akan memenuhi persyaratan Anda (pikirkan tentang ini lama-lama dan keras sebelum hanya mengatakan ya), maka itu adalah solusi yang bagus untuk saat ini, dan dalam beberapa tahun mungkin (ok, kemungkinan besar akan) melampaui NHibernate.
NHibernate adalah produk yang sangat matang dengan beberapa tahun di EF dan kemungkinan besar akan melakukan semua yang Anda ingin lakukan dan kemudian beberapa. Ini telah menjadi ORM terbaik untuk sementara waktu sekarang dan banyak orang menggunakannya.
Saya pikir fakta bahwa EF 4 akan memiliki kemampuan untuk menggunakan POCO dan pemuatan lambat yang ditangguhkan akan sangat besar. Saya pasti bisa melihatnya mendapatkan daya tarik dengan rilis baru.
Ada tren nyata peningkatan popularitas EF di NHibernate, lihat gambar.
2 sen saya: kami menggunakan ef di klien desktop kami untuk beberapa cahing dll - tanpa beban tinggi. NHib di sisi server - memanfaatkan sesi Stateless, pembuatan dan kumpulan id hilo. Cukup cepat dalam memasukkan pesan 3k + dalam db per detik. Juga sangat fleksibel dan mendukung banyak dbs, yang sangat penting untuk produk kami.
Pemetaan langsung ke prosedur tersimpan dengan kombinasi Linq untuk lapisan logis tampaknya merupakan pendekatan termudah. Tidak ada xml. Hasilkan sql hanya untuk kueri menarik yang jarang digunakan atau tidak cocok untuk prosedur tersimpan.
Objek memuat dan menyimpan melalui SP standar. Pendekatan ini memungkinkan penggunaan dua login sql. Satu untuk akses kelas melalui SPs (izin hanya eksekusi) dan satu untuk modul linq logis yang memungkinkan akses tabel langsung.
Memilih antara ORM berdasarkan popularitas bukanlah hal terbaik untuk dilakukan. Saya sudah mencoba pindah ke EF selama 2 tahun terakhir dan yang bisa saya katakan adalah, kenapa sih saya masih mencoba?
ATM sudut pandang saya tentang EF adalah: "Ini dibuat untuk sistem yang sangat kecil dan sangat kecil dengan tidak lebih dari 3 tabel dengan hubungan kurang dari 1 (0 lebih baik)".
Dan mengapa saya berpikir seperti itu? 1. Coba perbarui grafik terputus dan lihat model awal Anda;
Cobalah untuk membuat TPH dengan pohon yang diwarisi dalam dan Anda akan menemukan bahwa Anda diatur ke dalam satu hierarki atau sistem akan rusak.
Cobalah untuk membuat kueri yang lebih rumit dan lihat seluruh sistem menghabiskan tumpukan: D ... luapan sangat sering terjadi.
Tipe data XML peta didasarkan pada ekstensi atau properti NotMapped yang paling "dibenci" ... dan bahkan lebih buruk lagi.
Coba gabungkan kueri SQL ke dalam Linq untuk kueri yang lebih halus dan Anda akan merusak dindingnya lol.
Dan yang terakhir dan terpenting, EF tidak mendukung formula properti ('sumber daya yang luar biasa yang dimiliki NH untuk database lama'), dan tidak mendukung pemetaan tipe kompleks untuk tabel yang sama dan tabel terkait.
Itu 10cc saya.