it-swarm.asia

EntityFramework kullanarak başka tartışmalar nelerdir?

Şu anda inşa ettiğim uygulama, veritabanı nesnelerini temsil etmek için Saklı yordamları ve el yapımı sınıf modellerini kullanmaktadır. Bazı insanlar Entity Framework kullanmayı önerdi ve projeye o kadar da uzak olmadığım için buna geçmeyi düşünüyorum. Benim sorunum, EF için tartışan insanların bana sadece şeylerin iyi tarafını söylediklerini hissediyorum, kötü tarafı değil :)

Temel endişelerim:

  • DataAnnotations kullanarak İstemci Tarafı doğrulaması istiyoruz ve yine de istemci tarafı modelleri oluşturmam gerekiyor gibi görünüyor, bu yüzden EF'in bu kadar kodlama zamanından tasarruf edeceğinden emin değilim
  • Ağ üzerinden geçerken sınıfları olabildiğince küçük tutmak istiyoruz ve EF kullanmanın genellikle gerekli olmayan ekstra veriler içerdiğini okudum
  • Birden çok veritabanını geçen karmaşık bir veritabanı katmanımız var ve EF'in bunu başarabileceğinden emin değilim. Kullanıcılar, StatusCodes, Türler, vb. Şeyler içeren bir Ortak veritabanımız ve uygulamanın farklı örnekleri için ana veritabanlarımızın birden çok örneği var. SELECT sorguları, veritabanlarının tüm örneklerini sorgulayabilir ve sorgulayacaktır, ancak kullanıcılar yalnızca üzerinde çalışmakta oldukları veritabanındaki nesneleri değiştirebilir. Uygulamayı yeniden yüklemeden veritabanlarını değiştirebilirler.
  • Nesne modları çok karmaşıktır ve genellikle birkaç birleşim vardır

EF için argümanlar:

  • Eşzamanlılık. Kaydın her kayıttan önce güncellenip güncellenmediğini görmek için kontrollerde kod yazmak zorunda kalmazdım
  • Kod Üretimi. EF benim için kısmi sınıf modeller ve POCO'lar üretebilir, ancak doğrulama ve bazı özel ayrıştırma yöntemleri için hala istemci tarafı modeller oluşturmamız gerektiğini düşündüğüm için bu beni gerçekten çok zaman kazandıracağından emin değilim.
  • Her veritabanı nesnesi için CRUD saklı yordamları oluşturmamız gerekmediği için geliştirme hızı

Mevcut mimarimiz, parametrelenmiş Saklı Yordamlar aracılığıyla veritabanı çağrılarını işleyen bir WPF Hizmeti, WCF hizmetine ve WPF istemcisine giden/WPF istemcisine giden POCO nesneleri ve Doğrulama amacıyla POCO'ları sınıf Modellerine dönüştüren WPF masaüstü istemcisinin kendisinden oluşur. Bağlanma verileri.

Yani sorum şu: EF bunun için doğru mu? EF hakkında bilmediğim bir tuzak var mı?

31
Rachel

Kısa süre önce Entity Framework'ü değerlendiriyordum ve sorunlar ve eksik özellikler için bulduğum en iyi yer: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

En çok oy alan ürünler:

  1. Numaralandırma desteği. Bu oldukça büyük, ancak şu anda bazı geçici çözümler var
  2. Geliştirilmiş SQL üretimi. Hız, özellikle kurumsal düzeydeki uygulamalar için gerçekten önemlidir, ancak EF4 ile çok gelişmiştir gibi görünüyor
  3. Çoklu veritabanı desteği. Herhangi bir büyük uygulama için gereklilik.

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

Bir yan not olarak, İlk Kod yaklaşımı içerecek olan EF 4.1'in yakında çıkacağı konusunda oldukça heyecanlıyım ... http://blogs.msdn.com/b/adonet/archive/2011/03/15 /ef-4-1-release-candidate-available.aspx

Bu aslında beni bir üretim uygulamasında EF denemeye zorlayabilir.

7
Mag20

EF ile hata başına dal/özellik yapmak, birleştirme zamanında oldukça acı verici olabilir. A ve B'nin iki şubesinin veritabanında değişiklikler yaptığını düşünün (muhtemelen yeni bir projenin ilk aşamalarında çok şey olacaktır).

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

Merging Model.edmx o kadar acı verici ki, oldukça kötü bir şekilde Çalışır:

  • Birleştirme sırasında, yalnızca bir üst öğeden tüm birleştirmeleri seçin. Hangisi önemli değil; zaten dosyayı yakında tost edeceksiniz:
  • Model.edmx öğesini her iki ebeveyne geri döndürün.
  • Veritabanınızı yeni birleştirilmiş duruma geçirin.
  • Model.edmx dosyasını ve "Modeli Veritabanından Güncelle" yi açın.
  • Birleştirme sırasında kızarmış tüm gezinme özelliklerini yeniden adlandırın.
7
Frank Shearar

Eksik olduğunuz EF'in birkaç avantajı daha var:

  • Varlık yayılma tablolarınız olabilir
  • Bir tabloyu birçok Varlık türüne bölebilirsiniz
  • Varlıkları veritabanından oluşturabilirsiniz (yani ana yaklaşım olarak veritabanı)
  • Veritabanını Varlıklardan oluşturabilirsiniz (yani ana yaklaşım olarak kod)
  • LINQ sorguları SQL sorgularına dönüştürülerek performansları artırılır.

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] özniteliği oluşturmanız gerekir. Tüm özellikler object türündedir, bu nedenle meta verileri okumak için oradadır. Hala çok fazla aktif olmayan kod.
  • EntityFramework kullanmak, NHibernate (ve üst Java sürümü de)) gibi bir şeyin çalışmak üzere tasarlanma biçiminden farklı bir kavramdır. EntityFramework ekli modunda NHibernate ve benzeri ORM araçları, bağlantının yalnızca veri yüklenirken/kaydedilirken kullanıldığı ayrılmış modunda en iyi şekilde çalışır.

Bunlar benim en büyük iki şikayet. Bir dizi fayda var, ancak NHibernate'den aynı faydaları elde edebilirsiniz. EntityFramework masanın üzerinde ise, ekibin ayrıca NHibernate'e bakmasını sağlayın ve your projesi için artıları/eksileri için hızlı bir atış yapın.

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

Nesneleriniz için gerçek bir bağımsız mod olmaması, bir web ortamında yapabileceklerinizi sınırlar. Bağlı mod, bir dizi Microsoft yeniliğinin ortaya çıktığı masaüstü uygulamaları için daha iyidir. Müstakil mod mümkün, ama çok acı verici. Bu durumda alternatif bir araç kullanmak en iyisidir.

5
Berin Loritsch

Microsoft'un pek iyi olmadığı bir şey geriye dönük karşılaştırılabilirlikuyumluluk, özellikle yeni teknolojiler söz konusu olduğunda

Özellikle EF1 (.net 3.5), EF4'ten (.net 4.0) çok farklıdır - bir sonraki sürüm için de aynı durum ortaya çıkabilir.

Süre bekler ve teknolojinin nasıl olgunlaştığını görürdüm.

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

2
Ophir Yoktan
  • Basitçe ... Etki Alanı Modeli nadiren veritabanınızdaki ilişkisel modelin bir kopyasıdır. Bu yüzden bazı tabloları bir sınıfa eşlemek ve telin üzerine atmak sadece tembelliktir. Veritabanı 3 farklı tablo olmasına rağmen tablolar yerel olarak 1 nesneye eşlenebilir. Veritabanını akıllıca tasarlayın.
  • İkincisi, bu EF şeyler belirli sorgular oluşturamaz ve bunları yine de yazmanız gerekir.
  • 3. Alan Modeli doğrudan servislerle eşleşmez .. Biri sadece en az veri setini tel üzerinden DTO olarak itmek isteyecektir .. özellikle, mobil uygulamalarla iletişim kuracaksa.
  • 5. Test yeteneği ... Kod değişikliklerine karşı yeterli regresyon sağlayacak kadar ayrıntılı testler oluşturulamıyor ...
    ara ...

10 sayfalık bir diyalog yazabilirim. Ama, sadece Şirket X için biraz atmak app yazıyorsanız .. o zaman kimin umurunda. Ancak, bir yazılım ürünü geliştiriyorsanız ... çok daha anal olmanız gerekecek

1
user104468

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

Ana noktalar:

  • Tembel yükleme eksikliği
  • Kalıcı cehalet eksikliği
  • Varlık modelini kaydetmek için kullanılan dosya biçimi hem görselleştirme öğeleri içerir hem de varlık modelinin kendisi ekip 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/ EF'in performans ve LINQ desteğindeki diğer ORM'lerle karşılaştırıldığında en iyi olmadığını gösterir.

0
M.Sameer