Entity Framework 4 - NHibernate [kapalı]

Web'deki Entity Framework ilk sürümü hakkında çok konuşuldu (ayrıca stackoverflow'da) ve NHibernate gibi daha iyi bir alternatifimiz olduğunda bunun iyi bir seçim olmadığı açıktır. Ancak Entity Framework 4 ve NHibernate arasında iyi bir karşılaştırma bulamıyorum. Bugün NHibernate'in tüm .NET ORM'ler arasında lider olduğunu söyleyebiliriz, ancak Entity Framework 4'ün NHibernate'i bu konumdan çıkarmasını bekleyebilir miyiz? Bence Microsoft EF4'e gerçekten çok iyi özellikler enjekte etmişse, NHibernate'e iyi bir rekabet sağlayabilir, çünkü Visual Studio entegrasyonu vardır, çalışması daha kolaydır ve çoğu mağazada her zaman MS ürünleri tercih edilir.

EF4, "kendi kendini takip eden varlıklar" da n-katmanlı geliştirmeye ilişkin ezber bozan bir cevaba sahiptir. Hiç kimse NHib için benzer bir kod yayınlamadı.

NHib, EF4'ün bir parçası olarak bahsedilmeyen birçok özelliğe sahiptir. Bunlar, ikinci seviye önbellek entegrasyonunu içerir. Ayrıca, miras haritalamada daha fazla esnekliğe, depolanan işlemlerle / veritabanı işlevleriyle / özel SQL / tetikleyicilerle daha iyi entegrasyona, formül özellikleri için desteğe ve benzerlerine sahiptir. IMO, temelde bir ORM olarak daha olgundur.

Güncelleme: Sürüm 4.0'dan beri Entity Framework kullanmadım, bu yüzden cevabım eski olabilir. Projelerimde hala NH veya saf ADO .NET kullanıyorum. Ve 4.0'dan beri EF'teki yeniliklere bakmak bile istemiyorum çünkü NH mükemmel çalışıyor.

Aslında ikisini de kullandığınızda bunları karşılaştırmak oldukça kolaydır. EF4 ile bazı ciddi sınırlamalar var, kendimle karşılaştığım bazılarını isimlendirebilirim:

EF4 sorunları:

• Sonucu istekli yükleme ve şekillendirme : EF4 istekli yükleme sistemi (Include ("Path")), çoktan çoğa ilişkiler için binlerce (tam anlamıyla değil) zaman daha yavaş yürütecek ve ardından elle yazılmış SQL ( etkili bir şekilde kullanılamaz).
• Materyalizer ilişkili varlıkları gerçekleştiremez : Kendi SQL sorgunuzu sağlayarak önceki problemin üstesinden gelebileceğinizi düşünüyorsanız, yanılıyorsunuz. EF4, JOIN SQL sorgusundan ilişkili varlıkları gerçekleştiremez (eşleyemez), yalnızca bir tablodan veri yükleyebilir (Bu nedenle, Order.Product varsa, SELECT * FROM order LEFT JOIN Ürün yalnızca Order nesnesini başlatır, Ürün boş kalır, tüm gerekli verilerin, onu başlatmak için sorguda getirildiğini düşündü). EFExtensions topluluk eklentisi kullanılarak bu sorunun üstesinden gelinebilir, ancak bunun için yazmanız gereken kod gerçekten çirkin (denedim).

• Kendi Kendini İzleyen Varlıklar: Birçoğu, kendi kendini takip eden varlıkların, bu ileti dizisindeki en iyi yanıt dahil olmak üzere N katmanlı geliştirme için harika olduğunu söylüyor. Denemedim bile diyebilirim, her girdi sahte olabilir, kullanıcının size gönderdiği değişiklikleri basitçe alıp veri tabanına uygulayamazsınız, neden kullanıcıya doğrudan veri vermiyorsunuz? o zaman temel erişim? Kullanıcının veriyi yüklemesi gereken herhangi bir yol, DB'den değişmek üzeredir, var olup olmadığını kontrol edin | var olmadığını kontrol edin | izin kontrolleri yapın vb. Kullanıcıya, sunucuya gönderdiği varlığın durumuna güvenemezsiniz, yine de olacaksınız bu varlığı DB'den yüklemeli ve durumunu ve diğer şeyleri belirlemelisiniz, bu nedenle bu bilgi, dahili kullanım için özel bir güvenilir n katmanlı sistem yapmadığınız sürece Kendi Kendini İzleme varlıkları gibi işe yaramaz, bu durumda belki de sadece DB erişimi.

• Loglama, Etkinlikler, iş mantığını entegre etme: EF4 kara kutu gibidir, bir şeyler yapar ve ne yaptığı hakkında hiçbir fikriniz yoktur. DB ile bir şey olmadan önce çalıştırmanız gereken bazı iş mantığını koyabileceğiniz tek bir olay OnSavingChanges vardır ve bir şey olmadan önce iş nesnelerine bazı değişiklikler uygulamanız gerekirse ObjectStateManager'da kazmanız gerekir ve bu gerçekten çirkin bir durumdur. kod çok büyük olabilir. Örneğin, Depo modelini kullanıyorsanız ve DB'de temiz nesne şeklinde yapılan değişikliklerle ilgili olarak nelere bilgi verileceğini düşünüyorsanız, bunu EF ile yapmakta zorlanacaksınız.

• Genişletilebilirlik: Tüm EF kodları özel ve dahilitir, bir şeyi beğenmezseniz (ve EF kullanımı konusunda ciddiyseniz LOT'u sevmezseniz), bunu kolay bir şekilde değiştiremezsiniz, Aslında eminim Kendi ORM'nizi sıfırdan yazmak daha kolaydır (ben yazdım) ve ardından EF'in ihtiyaç duyduğunuz şekilde çalışmasını sağlayın. Örneğin, EFExtensions kaynağına bir göz atın, uzantı yöntemlerine ve EF'yi biraz daha kullanışlı hale getirmek için farklı "hack'lere" dayanıyor ve kod oldukça çirkin (ve EF'deki her şey özel olduğunda yazarların hatası değil, bu tek uzatmanın yolu).

EF hakkında kötü şeyler yazmaya devam edebilirim ve onunla 20 sayfa kadar çalışmanın benim için ne kadar acı verici olduğunu ve belki yazacağım.

NHibernate ne olacak? Kesinlikle farklı bir seviye, PHP'yi C # ile karşılaştırmak gibi, EF4 Taş Devri'ndeki gibi, EF'nin 10 yıl gerisinde olduğu gibi, NHibernate'in geliştirme sürecinde olduğu gibi ve aslında Hibernate 2001'de başlatıldı. Boş zamanınız varsa Nhibernate'i öğrenmek ve açmak için yapın.

İşte şey. NHibernate ve Entity Framework, aklımda gerçekten iki farklı kitle içindir. NHibernate, karmaşık eşlemeler, formüller ve kısıtlamalar (temelde herhangi bir işletme) içeren bir sistem oluşturmada benim seçimim olacaktır. Basit veri erişimiyle yere vurmak istersem Entity Framework veya LINQ-to-SQL kullanırdım. NHibernate, EF gibi net bir "sürükle ve bırak" deneyimine sahip değildir. Her ikisinin de güçlü ve sakıncaları vardır. Açıkçası onları elma ile elma karşılaştırmak sizi hiçbir yere götürmez.

Kodunuzu Mono'da çalıştırmak isteyebileceğinizi düşünüyorsanız, NHibernate, özellik kontrol listeleri ne derse desin muhtemelen daha iyi bir seçimdir ...

Düzenleme, 8/13/2012:

Entity Framework açık kaynaklı olmuştur ve artık 2.11.3 itibarıyla Mono'ya dahil edilmiştir. Bu cevap artık güncelliğini yitirmiştir ve buna güvenilmemelidir.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

Benim bu konudaki görüşüm, EF4.0'ın 1.0'dan beri uzun bir yol kat ettiği ve işlevsellikte Nhibernate'e yetiştiği, ancak henüz hepsi değil.

Ancak Microsoft, kutunun dışında ve uygulamaların% 95'inin yapması gerekenin% 100'ünü yapıyor. Ancak NHibernate yıllardır aynı şeyi yapıyor. Sürüm 5.0 veya 6.0 NHibernate'i yakalayabilir, hatta geçebilir.

İşte tavsiyem - ikisini de öğrenmek için vaktiniz varsa, yapın. Birini diğerine tercih etmenin birkaç nedeni vardır. Bir şirket için kod yazıyorsanız, tüm kitaplarda olduğu gibi ve çocukların üniversitede öğrendikleri gibi, EF'e aşina olabilecek çalışanlar olmasını beklemek gerçekçidir. EF gereksinimlerinizi karşılayacaksa (sadece evet demeden önce bunu uzun ve zor bir şekilde düşünün), o zaman bu şimdilik mükemmel bir çözüm ve birkaç yıl içinde (tamam, büyük olasılıkla) NHibernate'i geçebilir.

NHibernate, EF üzerinde birkaç yılı olan çok olgun bir üründür ve büyük olasılıkla yapmak isteyeceğiniz her şeyi ve daha sonra bazılarını yapacaktır. Bir süredir en iyi ORM oldu ve birçok insan bunu kullanıyor.

EF 4'ün POCO kullanma yeteneğine sahip olacağı ve ertelenmiş tembel yüklemenin çok büyük olacağını düşünüyorum. Yeni sürümle birlikte ilgi kazandığını kesinlikle görebiliyordum.

NHibernate'e göre EF popülaritesini artırma yönünde bariz bir eğilim var, resme bakın.

Benim 2 sentim: masaüstü istemcimizde bazı cahing vb. İçin ef kullanıyoruz - yüksek yük yok. Sunucu tarafında bir NHib - Durumsuz oturumlar, hilo kimliği üretimi ve toplu işlerden yararlanır. 3k + mesajlarını saniyede db olarak eklemede oldukça hızlıdır. Ayrıca çok esnektir ve ürünümüz için çok önemli olan birçok dbs'yi destekler.

Mantıksal bir katman için Linq kombinasyonuyla depolanan prosedürlere doğrudan eşleme yapmak en kolay yaklaşım gibi görünüyor. Xml yok. Sql yalnızca daha az sıklıkla kullanılan veya depolanmış prosedürler için uygun olmayan ilginç sorgular için oluşturun.

Nesneler standart SP'ler aracılığıyla yüklenir ve depolanır. Bu yaklaşım, iki sql girişinin kullanımına izin verir. SP'ler aracılığıyla sınıf erişimi için (yalnızca yürütme izinleri) ve doğrudan tablo erişimine izin veren mantıksal bir linq modülü için bir tane.

ORM'ler arasında popülerliğe göre seçim yapmak yapılacak en iyi şey değildir. Son 2 yılda EF'ye geçmeyi denedim ve tek söyleyebileceğim, neden hala denediğim?

ATM EF ile ilgili bakış açım: "1'den az ilişkiye sahip 3'ten fazla tablo içermeyen gerçekten küçük oldukça küçük bit sistemler için yapılmıştır (0 daha iyidir)".

Ve neden böyle düşünüyorum? 1. Bağlantısız bir grafiği güncellemeyi deneyin ve modelinizin çizikini görün;

1. Derin kalıtımsal ağaçlarla TPH yapmaya çalıştığınızda, tek bir hiyerarşiye bağlı olduğunuzu veya sistemin bozulacağını göreceksiniz.

2. Daha hantal sorgular yapmaya çalışın ve tüm sistemin yığını yemesini izleyin: D ... taşmalar çok sık olur.

3. Harita XML veri türleri uzantılara veya en "nefret edilen" NotMapped özelliklerine dayanır ... ve daha da kötüsü.

4. Daha ince sorgular için SQL sorgusunu Linq ile karıştırmayı deneyin ve duvar lol'ı kıracaksınız.

5. Ve son ve en önemli şey, EF, özellik formülünü desteklemiyor ('eski veritabanları için harika kaynaklar NH'nin sahip olduğu') ve aynı tablo ve ilgili tablolar için karmaşık tür eşleştirmelerini desteklemiyor.

Bu benim 10cc'm.