Entity Framework 4 vs NHibernate [ditutup]


114

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.


31
Saya ingin pembaruan dari perbandingan ini. Apa yang terjadi sejak '09?
Phil

Jawaban:


66

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.


13
+1 Anda benar. NH baru saja dewasa. EF akan menyusul pada akhir tahun ini. Versi 4.0 telah masuk secara dramatis. Beri waktu dan itu akan menjadi anti peluru pada pertengahan 2011.

15
-1 Untuk "EF4 memiliki jawaban out-the-box sehubungan dengan pengembangan n-tier, dalam" entitas pelacakan mandiri ". Tidak ada yang merilis kode yang sebanding untuk NHib." Ada ISession.Merge di NHibernate yang jauh lebih baik daripada entitas Self-Tracking untuk pengembangan N-Tier karena berbagai alasan.
Alex Burtsev

12
@ Alex - Dalam hal apa NHibernate merupakan solusi "di luar kotak"? Hanya untuk mengklarifikasi; "Di luar kotak" berarti ia bekerja dengan penginstalan vanilla dari Visual Studio. Itu adalah -1 yang tidak bisa dibenarkan di sana.
Dokter Jones

9
@DoctaJonez - Cara saya membacanya, Alex menentang gagasan bahwa NH tidak memiliki apa pun yang sebanding dengan entitas pelacakan mandiri, bukan bagian tentang hal itu "di luar kotak".
Jerph

2
Sebenarnya, saya telah menemukan bahwa EF4 memiliki pemetaan warisan yang lebih fleksibel. Misalnya, Anda dapat menggunakan 2 tabel (TPT) sebagai kelas dasar + kelas level 1 dan menambahkan diskriminator ke tabel level 1, memungkinkan pemisahan ke kelas level 2. Di NH, diskriminator hanya dapat didefinisikan pada kelas dasar.
Danny Varod

37

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.


1
EF telah dirilis di bawah lisensi Apache 2, yang seharusnya membantu ekstensibilitas.
CMircea

@MirceaChirea Itu, berita bagus, saya tidak menyangka ini, menjelajahi kode sumber EF sekarang, bacaan yang cukup menarik.
Alex Burtsev

2
-1 untuk membuat beberapa pernyataan yang diawali dengan "Saya belum pernah menggunakan ini, tapi saya tetap berbicara."
Kyeotic

@Tyrsius Jawaban saya ditulis, hampir 3 tahun yang lalu, saya sudah lama tidak menggunakan EF, beberapa hal dapat ditingkatkan, Anda dapat mengedit jawaban saya untuk memperbarui ke status EF saat ini.
Alex Burtsev

2
Anda mengakui bahwa Anda tidak pernah menggunakan entitas pelacakan sendiri, tetapi Anda menolaknya. Bagaimana jika hanya berbicara dengan apa yang Anda ketahui dan tinggalkan tebakan yang bodoh, terutama karena seluruh paragraf itu cukup salah.
Tom Halladay

25

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.


13
Sudahkah Anda mencoba ActiveWriter? Kerangka Entitas benar-benar ditargetkan pada ruang perusahaan. Saya tidak setuju dengan sebagian besar dari apa yang Anda katakan.
Michael Maddox

1
Tidak setuju dengan semua yang Anda inginkan tetapi fakta bahwa NHibernate telah ada lebih lama adalah sesuatu yang TIDAK diabaikan oleh perusahaan.
zowens

21
-1 Ini bukan perbandingan yang baik antara NHibernate vs. Entity Framework. Membandingkan keduanya dengan menggabungkan EF dengan LINQ ke SQL hanya b / c yang memiliki drag-and-drop paling tidak jujur. Sejauh kompleksitas, apa sebenarnya yang dapat dilakukan NHibernate yang tidak dapat dilakukan oleh EF 4?
Kevin Babcock

14
Cache Tingkat Kedua, kueri mereka SANGAT dioptimalkan, NH memaksa Anda untuk menggunakan pola UnitOfWork, ditambah pemetaan tidak macet ke dalam satu file. Pendapat saya (dari pengalaman) adalah bahwa NHibernate lebih berkinerja. Tidak setuju dengan saya tentang itu, tetapi saya mengatakan itu adalah pendapat saya. Maksud saya dalam jawaban saya adalah MASIH valid, mereka KEDUA memiliki kelebihan dan kekurangan. Tidak ada yang bisa menyangkal itu.
zowens

2
@ MakerOfThings7 itu menyedihkan ... seluruh pertanyaan ini subjektif. Bangun ...
zowens

23

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


Memang, dari mono-project.com/Compatibility itu membaca "EntityFrameworks - Not available.", Dan sepertinya tidak ada yang tertarik untuk mengimplementasikannya. Jadi setidaknya untuk beberapa tahun, ini NHibernate atau tidak sama sekali.
pengguna276648

12

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.


10

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.


7
Jangan lupakan dukungan LINQ. NHibernate masih belum pandai dalam hal itu.
Arnis Lapsa

1
@Arnis, dapatkah Anda memberikan tautan untuk mendukung pendapat itu?
Michael Maddox

2
@Michael ini terlihat ketika Anda melihat-lihat posting blog Ayande tentang masalah ini. LINQ ke NH didasarkan pada API kriteria saat ini. API kriteria tidak mengizinkan beberapa fungsi kueri yang lebih kompleks yang dapat dilakukan HQL. Rilis LINQ ke NH berikutnya akan menggunakan HQL sebagai ganti API kriteria.
zowens

5

Ada tren nyata peningkatan popularitas EF di NHibernate, lihat gambar.

Kerangka Kerja NHibernate vs Entity



Berdasarkan tren, orang-orang mulai lebih sering menggunakan EntityFramework di Google. Dan mereka mungkin punya alasan bagus untuk itu. Mungkin mulai menjadi lebih baik.
Tomas Kubes

Itu bisa menjadi kasusnya, bisa juga menjadi kasus yang disarankan secara default untuk digunakan oleh MS. Juga perkakas untuk EF cukup bagus.
Răzvan Flavius ​​Panda

4

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.


3

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.


1

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;

  1. Cobalah untuk membuat TPH dengan pohon yang diwarisi dalam dan Anda akan menemukan bahwa Anda diatur ke dalam satu hierarki atau sistem akan rusak.

  2. Cobalah untuk membuat kueri yang lebih rumit dan lihat seluruh sistem menghabiskan tumpukan: D ... luapan sangat sering terjadi.

  3. Tipe data XML peta didasarkan pada ekstensi atau properti NotMapped yang paling "dibenci" ... dan bahkan lebih buruk lagi.

  4. Coba gabungkan kueri SQL ke dalam Linq untuk kueri yang lebih halus dan Anda akan merusak dindingnya lol.

  5. 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.

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.