Entity Framework'ü kullanmalı mıyız?

31

Şu anda aşağıdaki yığınımız var:

VS 2005
Web formları
SQL Server 2005
IIS 6

Buna geçmeyi planlıyoruz:

VS 2010
MVC ve Web Formları
SQL Server 2008
IIS 7

Sorum şu ki, VS 2010 ile MVC'ye geçtiğimizde, Entity Framework (veya başka bir ORM), bir mikro ORM ( Massive gibi ) veya sadece düz SQL kullanmalı mıyız ?

VS 2010 hakkında okuduğum tüm öğreticiler veri işlemlerinde Entity Framework kullanmaya yöneliktir, ancak bu öngörülebilir gelecek için (5+ yıl) olacak mı?

Önemli ise, müşterilerimizin uygulamalarının 10 - 1000 aktif kullanıcısı olan herhangi bir yeri olabilir.

— guanome
kaynak

Şu anda Linq-to-SQL kullanıyor musunuz?

— Morgan Herlocker

— Ekim'de

4

SQL'i gelecekteki gelişiminizde doğrudan kullanmaktan kaçının. ORM veya EF neredeyse bir zorunluluktur. Veri erişim katmanınız için bir stratejiye sahip olmak için zaman ayırın. Bu kritik bir karardır ve önemsiz bir görev değildir. Siz ve ekibin öğrenmesi için yeterli zamanınız olduğundan emin olun. Yeni çekirdek teknolojinin takıma tanıtılması yönetilmelidir. Aracı seçin, materyali seçin, biraz eğitim alın, ... ardından değerlendirin ve karar verin.

— NoChance

2

Yeni veya mevcut veritabanları? EF sözleşmeleriyle yeni bir DB oluşturmak ve ORM'ler için inşa edilmemiş mevcut bir DB'nin üzerine EF'yi güçlendirmeye çalışmak arasında potansiyel olarak büyük bir fark var.

— rmac

@ rmac Yeni bir veritabanı içindi.

— guanome,

45

Geçenlerde satır içi SQL sorguları kullanmaktan EF kullanmaya başladım ve işte bulduklarım:

Artıları

DAL oluşturmak için çok daha hızlı (SQL sorguları yazmamayı seviyorum!)
Bakımı çok daha kolay
Satır içi bir sql deyimi oluşturmadan önce girdilerimi ayrıştırmaya artık gerek yok, bu da bir SQL enjeksiyon saldırısı için daha az şans anlamına gelir (tabii ki, sorgularınıza bağlı olarak hala mümkündür, ancak daha az olasılıkla)

Eksileri

Birden fazla veritabanına yayılamaz ... en azından kolay değil
Tüm varlıklar (tablo, görünüm vb.) Birincil anahtara ihtiyaç duyar
100'den fazla gerekli sütunlar tablosunda (tablo tasarımım değil) tek bir sütunu güncellemek istiyorsanız, güncellemeyi yapmak için 100 sütunun tümünü aşağı çekmeniz gerekir. Veya Saklı Prosedür kullanın.
Yeni bir kayıt eklendikten sonra SQL sunucusunda tanımlanmış bazı varsayılan değerlerin varlık modeline alınmamasıyla ilgili sorunlar yaşadım. Genellikle bu hesaplanan değerlerle veya bir INSERT Tetikleyicisine eklenen değerlerle yapılır
Bazen, SQL sorguları kötü yazılmış ve yürütmek için yavaş. Yavaş çalışan bir sorunuz varsa, EF'nin ne yaptığını görmek için bir SQL izleme çalıştırın. Bu sorguyu bir SP veya Görünüm olarak yeniden çalıştırabilirsiniz. Bu olsa sık olmuyor.
SQL Server'da tanımlanmış bir Yabancı Anahtar olmayan tablolar arasında bir ilişki oluşturmaya çalışırken birkaç sorun yaşadım. Genellikle bunun nedeni 1:0-1EF’in kullanmak istediği bir ilişki kurmaya çalışıyorum.1:0-*

Yine de EF uzmanı değilim, muhtemelen bazı şeyleri özlemişimdir. Bunlar sadece, satır içi SQL'den Entity Framework'e geçerken geçmişte karşılaştığım tanıdıklarım. Geçiş yaptığım için mutluyum, ancak tuhaflıklar nedeniyle EF'ten gerçekten nefret ettiğim zamanlar oldu.

— Rachel
kaynak

7

Ayrıntılı ve organize cevap için +1. "Tüm varlıklar (tablolar, görünümler, vb.) Bir birincil anahtara ihtiyaç duyarlar" sesleri bir con yerine makul bir kısıtlama gibi.

— NoChance

2

@EmmadKareem Eğer veritabanı üzerinde kontrole sahipseniz, ancak bir üçüncü taraf veritabanıyla veya görünümlerle çalışıyorsanız, bu biraz can sıkıcı olabilir

— Rachel

1

Sadece bağlantısız bir N-katmanlı web uygulamasında EF'i kullanmayı deneyin - bir oturumdaki varlıkların güncellenmesi ve MM ilişkileri, hmmmmm ne eğlenceli!

— Vidar

5

@ EmmadKareem varlıkları gerçekten tek bir değerli ana anahtara ihtiyaç duyarlar - bileşik anahtarlar kullanmak EF'de bir kabustur. Bu makul bir kısıtlamadan ziyade bir aleyhtedir.

— Kirk Broadhurst

1

Güvenlik başka bir konu olduğunu söyleyebilirim. Pek çok kişi, tüm oturum açma girişlerinin, hangi oturum açma işlemlerinin depolanan işlemleri yürütebileceğini belirlemek için procs ile ilişkili DB rolleri ile saklı prosedürlerden geçmesi gerektiğini düşünüyor. Bu, sorgular oluşturmak için EF / LINQ’yi dışlar. EF kullandım ancak bu güvenlik gereksinimlerine sahip müşterilere ( öksürük Microsoft'a) rastladım

— Mick

12

Entity Framework bir verimlilik aracıdır. Olmaması için iyi bir nedeniniz yoksa (EG, SQL 2000’de ya da teknolojiyi geliştirmek için vaktiniz yoksa), emrinde en iyi araçları kullanın.

Söyleniyor, MVC modelinin Modeline çok iyi çevirmek için Varlıklar kavramını buldum. Modeller ve tablolar ile 1: 1 ilişki kurarken kötü bir uygulama olsa da, Varlıklar açısından düşünmek, temiz tasarımlar üretme eğilimindedir, okunması kolay kod (özellikle LINQ ile).

Entity Framework, Microsoft tarafından aktif olarak desteklenmektedir. Kimsede "destek X yıl sürecek" diyen sihirli bir kristal topa sahip değil. Gelecek 5 yıl içerisinde İşletmenin öleceğine inanmak için hiçbir sebep göremiyorum.

— P.Brian.Mackey
kaynak

3

LinqToSql oldukça hızlı bir şekilde öldü, bu yüzden bir yoldan ya da diğerinden Entity Framework'ün hayatta kalacağına inanmak için hiçbir neden yok. MS’in Metro’ya yaptığı yeni baskıyı, tekliflerinin çoğunu elden geçirmeyi düşündüğü ölçüde dikkate almaya değer.

— ocodo

3

Slomojo, 'Ölü' kelimesinin dünyasının geri kalanından farklı bir tanımı olabilir. Çünkü LinqToSql artık aktif olarak geliştirilmiyor. Bundan 10-20 yıl sonra yine de kullanabileceksiniz.

— Boris Yankov

4

Diğer bir potansiyel çözüm ise, VS ile birlikte temin edilemeyen alternatif bir Entity Framework Kütüphanesi kullanmaktır.

Entity / 3 katmanlı çerçeve konsepti, bir süredir orada ve Microsoft kendi “resmi” çerçevesini yayınlamadan önce, diğer birçok geliştirici gibi bazı özel kütüphanelerle birlikte çalışmıştı.

Artıları

Varlık (DAL) çerçevesinin avantajlarından, Microsoft sabit kitaplık / çerçeve değişikliklerinden etkilenmeden faydalanın.

Birkaç dtabase markasını kullanmak gibi, mevcut resmi kütüphanede bulunmayabilecek bir kütüphaneye özellikler eklemek.

Eksileri

Kütüphaneyi veya araçları desteklemek zorundasınız. Enititleri üretmek için bir Varlık üreteci kod aracına sahip olmak çok yaygındır.

— umlcat
kaynak

Bu cevabı çok kafa karıştırıcı buluyorum. Microsoft'un ürettiği yalnızca bir Varlık Çerçevesi (büyük harflerle) vardır. "Başka bir nesne ilişkisel eşleştiricisi kullan" mı demek istiyorsun? Entity Framework genel bir terim değildir - Microsoft’un ORM’inin adıdır.

— Nick

Bir “Microsoft Entity Framework” olduğu düşünüldüğünde, “Entity Framework” kavramı birkaç yıldır varlığını sürdürmektedir.

— Umlcat

3

Probleme ve mevcut çözüme dayalı bir mimari karar vermelisiniz. Herhangi bir teknolojide olduğu gibi avantajlar ve dezavantajlar vardır.

Ben şahsen normal olarak varlık çerçevesini yeni gelişme için kullanırdım ancak mevcut kodu çalıştırarak yeniden yazmam. Daha sonra gelecekteki gelişmeler için hız kazanırsınız ancak kod dönüştürme için çok fazla zaman harcamak zorunda kalmazsınız. Bu yaklaşımın dezavantajı tutarlılığı azaltmasıdır.

— Tom Squires
kaynak

3

Çalışma kodunu tekrar yazmamanızı önermek için +1.

— NoChance

2

Senin durumunda kesinlikle Entity Framework'ü kullanırdım, MVC ile iyi çalıştığını buldum.
İşte bazı gerçek sebep ve işaretçiler.

Linq kullanmak bir zevktir ve gecikmeli uygulama da son derece yararlıdır.
Mvc ile kullanarak Sana veri modelleri ile birlikte görünümü modelleri kullanmak salık ediyorum zaman ancak (modellerinizi oluşturabilir, bu o yaklaşım kullanımının almak yaparsanız doğrulama ve model, çok daha kolay bağlanmasını kolaylaştırır automapper üzerine geri değişiklikleri eşleştirmek için sizin veri örneği).

Bununla birlikte, bir ORM kullanımı hakkında öğrenmeniz gereken bazı şeyler vardır.

Bağlamın sizin için ne yaptığını (varlık takibi)
Bir bağlamın iş birimi olarak kullanılması gerektiği
Eşzamanlılık hakkında bir şey unutmayın, EF, nesnenizin güncelliğini kaybettiğinde size söyler, ancak istekler arasında eşzamanlılığı doğru bir şekilde ele almak istiyorsanız biraz zaman alabilir (bir zaman damgası veya başka bir şey tutmanız gerekir).

Düşünülmesi gereken şeyler

Tetikleyiciler ve ORM'ler birlikte çalışmaz, bunun yerine ORM olaylarını kullanın.
Tüm masalarınızın özel anahtarlara sahip olduğundan emin olun.

Ayrıca, varolan bir veritabanınız olsa bile, ilk önce kod yaklaşımını şiddetle tavsiye ederim.

Kurallar, veritabanını değiştirdiğinizde eşlemeleri veya sınıfları oluşturmanıza gerek olmadığı anlamına gelir.
Modellerde doğrulama ve diğer mantıkları yerleştirmek çok isteklidir.
Var olan çok büyük bir veritabanınız varsa, kod oluşturucuyu kullanmanıza yardımcı olabilirsiniz.

— Daniel Little
kaynak