EntityFramework'u kullanmaya KARŞI Bazı argümanlar nelerdir? [kapalı]

31

Şu anda yapıyorum uygulama veritabanı nesneleri temsil etmek için Stored prosedürleri ve el yapımı sınıf modelleri kullanıyor. Bazı insanlar Entity Framework kullanmayı önerdiler ve projeye o kadar uzak olmadığım için buna geçmeyi düşünüyorum. Benim sorunum, EF için tartışan insanların bana kötü şeyleri değil, sadece iyi şeyleri anlattıklarını hissediyorum :)

Asıl endişelerim:

DataAnnotations kullanarak İstemci Tarafı doğrulaması istiyoruz ve öyle görünüyor ki yine de istemci tarafı modeller oluşturmam gerekiyor, böylece EF'nin bu kadar kodlama süresinden tasarruf edeceğinden emin değilim.
Ağ üzerinden geçerken sınıfları olabildiğince küçük tutmak istiyoruz ve EF kullanmanın genellikle gerekmeyen ekstra veriler içerdiğini okudum.
Birden fazla veritabanını geçen karmaşık bir veritabanı katmanına sahibiz ve EF'in bunu kaldırabileceğinden emin değilim. Kullanıcılar, Durum Kodları, Türler, vb. Gibi şeyler içeren bir Ortak veritabanımız ve uygulamanın farklı örnekleri için ana veritabanlarımızın birden fazla örneği. SELECT sorguları veritabanlarının tüm örneklerini sorgulayabilir ve sorgulayacaktır, ancak kullanıcılar yalnızca üzerinde çalıştıkları veritabanında bulunan nesneleri değiştirebilir. Uygulamayı yeniden yüklemeden veritabanlarını değiştirebilirler.
Nesne modları çok karmaşık ve çoğu zaman katılan birkaç üye var.

EF için bağımsız değişkenler:

Eşzamanlılık. Her kayıttan önce kaydın güncellendiğini görmek için çeklerde kod yazmam gerekmeyecekti
Kod Üretimi. EF benim için kısmi sınıf modelleri ve POCO'lar üretebilir, ancak onaylama ve bazı özel ayrıştırma yöntemleri için hala müşteri tarafı modeller oluşturmamız gerektiğini düşündüğümden bu zamandan çok tasarruf edeceğinden emin değilim.
Her veritabanı nesnesi için CRUD saklı yordamları oluşturmamız gerekmediğinden geliştirme hızı

Mevcut mimarimiz, parametreli hale getirilmiş Kayıtlı Prosedürler, WCF servisine ve WPF istemcisine giden / giden POCO objeleri ve WPF istemcisinden veri tabanına çağrı yapan bir WPF Servisinden ve POCO'ları Doğrulama amacıyla sınıf Modellerine dönüştüren WPF masaüstü istemcisinden oluşmaktadır. Bağlanma verileri.

Öyleyse sorum şu, EF bunun için doğru mu? EF ile ilgili bilmediğim tuzaklar var mı?

architecture orm entity-framework

— Rachel
kaynak

Bunu da kontrol edin .. performans ve LINQ desteği karşılaştırması: ormeter.net

— M.Sameer 16:11

7

Son zamanlarda Entity Framework'ü değerlendiriyordum ve sorunlar ve eksik özellikler için bulduğum en iyi yer şuydu: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

En çok oy alan öğeler:

Enums için destek. Bu oldukça büyük, ancak şu anda bazı geçici çözümler var.
Geliştirilmiş SQL üretimi. Hız, özellikle kurumsal düzeydeki uygulamalar için gerçekten önemlidir, ancak EF4 ile çok gelişti gibi görünüyor
Birden fazla veritabanı için destek. Herhangi bir büyük uygulama için gereklilik.

Kullanıcı Sesi listesinde daha birçok sorun var.

Bir yandan not: İlk Kod yaklaşımını içerecek olan EF 4.1'in yayınlanması konusunda oldukça heyecanlıyım ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-salım aday-available.aspx

Bu aslında bir üretim uygulamasında EF denemek için beni zorlayabilir.

— Mag20
kaynak

Karşı tartışma: 1. ve 2. ve 3.: Bu YAVAŞ !!! Bir öğrenme eğrisi var (sol bir birleşmenin nasıl yapılacağını bilmeniz gerekir - bunu yapmanın bir yolunu bulmak için 3 saat sürer, böylece başka bir kişi ne yapıldığını bilecektir ...), SQL yerine LINQ'e çağrı yapın (ör. Feches 10 milyon satır, sonra bunların 20'sini keyfi bir dengelemeden alıyor ve sonra neden bu kadar yavaş olduğunu merak ediyorsunuz). Repo Basamaklı güvenli değil, sorgu bazında başlatmanız gerekiyor ve repo başlatma ÇOK YAVAŞ (5 saniye gibi) daha büyük bir veritabanınız varsa (yani 100-200 tablo, GERÇEKTEN GERÇEKTEN büyük değil).

— Quandary

2

@Quandary LINQ ifadeleriniz tam olarak tanımlanmadan önce IQueryables (yani çağırıyor .ToList()veya .ToArray) yapıyor gibi görünüyorsunuz . Bu yüzden tüm kayıtları alıyor ve yavaşlatıyor.

— orad

6

EF başına hata başına şube / özellik yapmak, birleştirme sırasında oldukça acı verici olabilir. İki A ve B şubesinin veritabanında değişiklikler yaptığını düşünün (ki bu muhtemelen yeni bir projenin ilk aşamalarında çok olacaktır).

Tüm "normal" dosyaları - cs dosyalarını vb. Birleştiriyorsunuz. Ve sonra Model.edmx'i birleştirmenin zamanı geldi. Ve birdenbire, sadece nesne modeliniz ve veritabanınız arasındaki mantıksal eşlemeleri değil, aynı zamanda varlık diyagramındaki tabloların konumlarını birleştiriyorsunuz.

Birleştirme Model.edmx o kadar acı verici ki, İşler Oldukça Kötü Bir Şekilde Kabul Ettik:

Birleştirme sırasında, yalnızca bir üst öğeden tüm birleştirmeleri seçin. Hangisi önemli değil; Yine de dosyayı tost olacaksınız:
Model.edmx öğesini her iki öğeye döndürün.
Veritabanınızı yeni birleştirilmiş duruma geçirin.
Model.edmx ve "Modeli Veritabanından Güncelle" yi açın.
Birleştirme sırasında kızartılan tüm gezinti özelliklerini yeniden adlandırın.

— Frank Shearar
kaynak

1

Bu eleştiri EF Kodu İlkesi için geçerli değildir, ancak Birinci Model ve İlk Veri Tabanı için geçerlidir.

— Alan Macdonald

Tüm eşlemeleri Fluent kullanarak kendim yaratıyorum ve eşlemenin tüm denetimini ele alıyorum. Bunlar ayrı bir .cs dosyasının içine yerleştirilir.

— Steven Ryssaert

5

Kaçırdığınız EF’nin bir kaç yararı daha var:

Varlık yayılma tablolarına sahip olabilirsiniz
Bir tabloyu birçok Varlık türüne bölebilirsiniz
Varlıkları veritabanından oluşturabilirsiniz (örn. Ana yaklaşım olarak veritabanı)
Veritabanını Varlıklar'dan oluşturabilirsiniz (ör. Ana yaklaşım olarak kod)
LINQ sorguları, performanslarını artırarak SQL sorgularına çevrilir.

Dezavantajları (özellikle doğrulama kullanıyorsanız):

Uygun doğrulama nitelikleriyle doğrulamak istediğiniz özelliklere sahip başka bir sınıfa işaret eden bir [MetadataClass] özelliği oluşturmanız gerekir. Tüm özellikler objecttürlerdir, bu nedenle meta verileri okumak için oradadır. Hala çok fazla aktif olmayan kod var.
EntityFramework kullanmak, NHibernate (ve aynı zamanda Java sürümünün) gibi bir şeyin çalışması için tasarlandığından farklı bir kavramdır. EntityFramework , nesnelerin her zaman canlı bağlantı kullandığı ekli bir modda en iyisini yapar . NHibernate ve benzeri ORM araçları , bağlantının yalnızca veri yüklerken / kaydederken kullanıldığı ayrık modda en iyi şekilde çalışır .

Bunlar en büyük iki şikayetim. Çok sayıda avantaj var, ancak aynı yararları NHibernate'den de alabilirsiniz. EntityFramework masada ise, takım da NHibernate kontrol etmek ve için lehte / aleyhte için hızlı çekim yapmak zorunda sizin proje.

Meta veri sınıfı problemi bir baş ağrısıdır, ama neyse ki sadece doğrulama etiketlerine ihtiyaç duyan çok fazla varlığım var.

Nesneleriniz için gerçek bir ayrılmış modun olmaması, web ortamında yapabileceklerinizi sınırlar. Ekli mod, bir dizi Microsoft yenilikinin ortaya çıktığı masaüstü uygulamaları için daha iyidir. Müstakil mod mümkündür , ancak çok acı vericidir. Bu durumda alternatif bir araç kullanmak en iyisidir.

— Berin Loritsch
kaynak

Sizin sözde usta olarak kod yaklaşımı olduğunu resmen denilen ilk kod

— Robert Koritnik

1

@Berin, "ekli mod" ile ne demek istediğinizi netleştirmek istiyorum. Entity Framework’ün her zaman açık olan veritabanıyla bir bağlantısı olduğunu sanmıyorum. EF’in NHibernate’ye benzer şekilde çalıştığını düşünüyorum. Kastettiğin bu mu yoksa başka bir şey mi kastediyorsun? Bu ekli konuyu daha fazla açıklayan belgelere bir bağlantınız var mı?

— RationalGeek

1

Ek olarak, nesnelerle olan tüm etkileşimlerinizin yapı içinde gerçekleşmesi gerektiği anlamına gelir using(EFConnection conn = new EFConnection). Hızlı bir güncelleme yapıp tekrar ikinci bir using(...)ifadede saklayabilmeniz için bu nesneyi güvenli bir şekilde saklamak için bir yere koymaya çalışırsanız, tekrar düşünmeniz gerekir. Bkz msdn.microsoft.com/en-us/library/bb896271.aspx ve msdn.microsoft.com/en-us/library/bb896248.aspx . EF 3.5 kullanmak (son sürümde kullanmak zorunda kaldım) o kadar da temiz değil.

— Berin Loritsch

Tamam, şimdi ne demek istediğini anlıyorum. İnsanların bunu her zaman veritabanına bir bağlantı olduğu anlamına gelmediğinden emin olmak istedim . "Eklenmiş" varlıkların durumunu koruyan bir nesne bağlamına sahip olmalısınız.

— RationalGeek

2

Bu doğru değil. EF, güçlü bir bağımsız varlık kavramına sahiptir. Bağlamsal bir varlığın, kendisine karşı bağlamla ilgili işlemleri gerçekleştirmeden önce (veritabanında güncelleme gibi) bağlamına yeniden bağlanması gerekir. Ayrıca meta veri sınıfları, ancak EF sizin için varlıklarınızı oluşturduğunda gereklidir. POCO'lar, IMO, EF'i kullanmanın çok daha iyi bir yoludur. POCO'ları kullanmak özellikle testlerde çok daha kolay.

— Matt Greer

2

Microsoft'un çok iyi olmadığı şeylerden biri , özellikle yeni teknolojiler söz konusu olduğunda geriye dönük ~~karşılaştırılabilirlik~~ uyumluluğu

Spesifik olarak EF1 (.net 3.5) EF4'ten (.net 4.0) çok farklı - bir sonraki sürüm için aynı olabilir.

Bir süre bekleyip teknolojinin nasıl olgunlaştığını görecektim.

Bu arada, nHibernate kullanmayı düşünün - eşdeğer değil, ancak olgun ve çılgınca kullanılmış.

— Ophir Yoktan
kaynak

1

Basitçe ... Etki Alanı Modeli nadiren veritabanınızdaki ilişkisel modelin bir kopyasıdır. Bu yüzden bazı masaları bir sınıfa eşlemek ve telin üstüne atmak sadece tembellikten ibarettir. Veritabanının 3 farklı tablo olmasına rağmen tablolar yerel olarak 1 nesneye eşlenebilir. Veritabanını akıllıca tasarlayın.
İkincisi, bu EF konusu belirli sorgular oluşturamaz ve yine de bunları yazmanız gerekir.
3. Etki Alanı Modeli doğrudan hizmetlere eşlenmez .. Biri tel üzerinden en az veri kümesini DTO'lar olarak zorlamak isteyecektir .. özellikle, mobil uygulamalarla iletişim kuracaksa.
5. Test yeteneği ... Kod değişikliklerine karşı yeterli gerileme sağlayacak kadar ayrıntılı testler oluşturulamaz ... hepsi kolay
kırılır ...

10 sayfalık bir yazı yazabilirim. Ancak, sadece X Şirketi için bir kenara atma uygulaması yazıyorsanız .. kimin umrunda. Ancak, bir yazılım ürünü geliştiriyorsanız ... çok daha anal olmanız gerekecek

— user104468
kaynak

Bu yazı okumak oldukça zordur (metin duvarı). Sakıncası var düzenleyebilir daha iyi bir şekle ing?

— gnat

EF, etki alanı nesneleri oluşturmaz. Bunlar DAO. Etki alanı nesnesini oluşturmak için nesnedeki verileri kullanmanız gerekir. Zaten bir hizmetten etki alanı nesneleri geri göndermemelisiniz, bu nedenle geri dönmeden önce inceltici DTO'yu etki alanı nesnelerinizden oluşturun. EF üretmek mümkün olmalıdır çoğu LINQ ifade edebilmeleri şey. Veritabanı bir birim testinin parçası değil, işlevsel bir testin parçası. Bununla birlikte, EF için uygun olan bellek taklitçileri var. Aksi takdirde EF sorgularınızı bir depoya ekleyin ve bununla alay edin.

— Sinaesthetic

Evet, aynı fikirdeyim .Ben daha Martin Martin ve Carig Lairman tarafından oluşturulan kalıpları kastediyorum. Günün sonunda CTE, PARTITION BY veya CROSS APPLY kullanamıyorum. Ayrıca, hafızanın ek yükünü düşük tutabilmek için IDataReader kullanamıyorum. Ayrıca, SQL

— Trace'ı

0

Şuna bir bakın : http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Ana noktalar:

Tembel yükleme eksikliği
Sebat yokluğu cehalet
Varlık modelini kaydetmek için kullanılan dosya formatı hem görselleştirme öğelerini içerir hem de varlık modelinin kendisi takım ortamında birleştirme sorunlarına neden olur.

Yukarıdaki bağlantının EF1 hakkında konuştuğunu unutmayın.

Ayrıca bu bağlantı: http://ormeter.net/ , performansın ve LINQ desteğindeki diğer ORM'lerle karşılaştırıldığında EF’in en iyi olmadığını gösteriyor.

— M.Sameer
kaynak

Bunun EF 1 hala yeni çıktığında (veya muhtemelen hala beta sürümünde) yayınlandığını unutmayın. Bugün EF 4 ile durum çok daha iyi ve bu oylamada ortaya çıkan sorunların çoğu güvenilmez olarak çözüldü.

— RationalGeek

Son nokta hala sayılır ve çok önemlidir.

— M.Sameer

1

İlk EF versiyonu 3.5 idi. Yayımlanan dört ana EF sürümü bulunmuyor.

— Matt Greer

3

@Matt doğru. Ancak mevcut sürüme, .NET 4 sürümünün geri kalanıyla uyum sağlamak için EF 4 adı verilir.

— RationalGeek

1

Yine de geçerli olup olmadığı, bağlantının özetini etkilememelidir. Oylar geçerli olup olmadığını gösterecektir. :)

— Adam Lear