Entity Framework VS LINQ to SQL VS ADO.NET saklı yordamlar ile? [kapalı]

Her birini şu şekilde nasıl değerlendirirsiniz:

1. Verim
2. Geliştirme hızı
3. Düzgün, sezgisel, bakımı kolay kod
4. Esneklik
5. tüm

Ben SQL gibi ve bu yüzden her zaman ADO.NET ve saklı yordamlar çok zor bir hayranıydım ama son zamanlarda Linq to SQL ile bir oyun vardı ve benim DataAccess katmanı yazma ne kadar hızlı tarafından uçurulmuştu ve harcama karar verdik bir süre Linq to SQL ya da EF ... ya da hiçbiri gerçekten anlamak?

Sadece bu teknolojilerin hiçbirinde araştırma zamanımı işe yaramaz hale getirecek büyük bir kusur olmadığını kontrol etmek istiyorum. Örneğin, performans korkunç, basit uygulamalar için harika, ancak sizi şu ana kadar alabilir.

Güncelleme: ORM VS SP'ler yerine EF VS L2S VS SP'lere konsantre olabilir misiniz? Esas olarak EF VS L2S ile ilgileniyorum. Ancak, düz SQl hakkında çok şey bildiğim bir şey olduğundan, onları depolanan proc'larla karşılaştırmaya meraklıyım.

Öncelikle, yeni bir projeye başlıyorsanız, Entity Framework ("EF") ile devam edin - artık çok daha iyi SQL üretir (Linq to SQL gibi) ve Linq to SQL'den daha kolay ve daha güçlüdür (" L2S "). .NET 4.0'ın piyasaya sunulmasından itibaren, Linq to SQL'i eski bir teknoloji olarak görüyorum. MS, L2S gelişimini daha fazla sürdürmeme konusunda çok açıktı.

1) Performans

Cevaplamak zor. Çoğu tek varlıklı işlem ( CRUD ) için, üç teknolojinin tamamında neredeyse eşdeğer bir performans bulacaksınız. EF ve Linq to SQL'in tam olarak kullanılabilmesi için nasıl çalıştığını bilmek zorundasınız. Yoklama sorguları gibi yüksek hacimli işlemler için, EF / L2S'nin varlık sorgunuzu çerçevenin sürekli olarak SQL'i yeniden oluşturmak zorunda kalmayacağı veya ölçeklenebilirlik sorunlarıyla karşılaşabileceği şekilde "derlemesini" isteyebilirsiniz. (düzenlemelere bakın)

Çok miktarda veri güncellediğiniz toplu güncellemeler için, ham SQL veya saklı bir prosedür her zaman bir ORM çözümünden daha iyi performans gösterecektir, çünkü güncellemeleri gerçekleştirmek için kablo üzerinden veriyi ORM'ye marshallemek zorunda kalmazsınız.

2) Geliştirme Hızı

Çoğu senaryoda EF, geliştirme hızı söz konusu olduğunda çıplak SQL / depolanmış proc'ları patlatacaktır. EF tasarımcısı, modelinizi değiştikçe veritabanınızdan güncelleyebilir (istek üzerine), böylece nesne kodunuz ve veritabanı kodunuz arasında senkronizasyon sorunlarıyla karşılaşmazsınız. Bir ORM kullanmayı düşünmediğim tek zaman, güncelleme yapmadığınız bir raporlama / pano tipi uygulama yaptığınızda veya sadece bir veritabanında ham veri bakım işlemleri yapmak için bir uygulama oluştururken.

3) Düzenli / Sürdürülebilir kod

Eller aşağı, EF SQL / sprocs'u yener. İlişkileriniz modellenmiş olduğundan, kodunuzdaki birleştirmeler nispeten nadirdir. Varlıkların ilişkileri, çoğu sorgu için okuyucu için neredeyse açıktır. Verilerinize gerçekte ne olduğunu anlamak için katmandan katmana hata ayıklamaya veya birden çok SQL / orta katmana gitmek zorunda kalmaktan daha kötü bir şey yoktur. EF, veri modelinizi çok güçlü bir şekilde kodunuza getirir.

4) Esneklik

Kayıtlı işlemler ve ham SQL daha "esnektir". Tek özel durum için daha hızlı sorgular oluşturmak için sprocs ve SQL'den yararlanabilirsiniz ve yerel DB işlevlerinden ve ORM'den daha kolay yararlanabilirsiniz.

5) Genel

Saklı yordamları kullanarak bir ORM seçmenin yanlış ikilemine kapılmayın. Her ikisini de aynı uygulamada kullanabilirsiniz ve muhtemelen kullanmalısınız. Büyük toplu işlemler saklı yordamlarda veya SQL'de (aslında EF tarafından çağrılabilir) yapılmalıdır ve EF, CRUD işlemleriniz ve orta katman gereksinimlerinizin çoğunda kullanılmalıdır. Belki de raporlarınızı yazmak için SQL kullanmayı tercih edersiniz. Sanırım hikayenin ahlaki her zamanki gibi. İş için doğru aracı kullanın. Ama sıska, EF bugünlerde çok iyi (.NET 4.0'dan itibaren). Bunu okumak ve anlamak için gerçek zamanlı biraz zaman harcayın ve kolayca şaşırtıcı, yüksek performanslı uygulamalar oluşturabilirsiniz.

DÜZENLEME : EF 5, otomatik derlenmiş LINQ Sorguları ile bu bölümü biraz basitleştirir , ancak gerçek yüksek hacimli şeyler için, gerçek dünyada sizin için en uygun olanı kesinlikle test etmeniz ve analiz etmeniz gerekir.

Saklı yordamlar:

(+)

• Mükemmel esneklik
• SQL üzerinde tam kontrol
• Mevcut en yüksek performans

(-)

• SQL bilgisi gerektirir
• Saklı yordamlar kaynak denetimi dışında
• Aynı tablo ve alan adlarını belirlerken önemli miktarda "kendinizi tekrar etme". Bir DB varlığını yeniden adlandırdıktan ve bir yerde bazı referansları kaçırdıktan sonra uygulamayı kırma olasılığı yüksektir.
• Yavaş gelişme

ORM:

(+)

• Hızlı gelişim
• Veri erişim kodu artık kaynak kontrolü altında
• DB'deki değişikliklerden izolesınız. Böyle bir durumda, modelinizi / eşlemelerinizi tek bir yerde güncellemeniz gerekir.

(-)

• Performans daha kötü olabilir
• ORM'nin ürettiği SQL üzerinde hiç veya çok az kontrol (verimsiz veya daha kötü bir hata olabilir). Müdahale edilmesi ve özel saklı prosedürlerle değiştirilmesi gerekebilir. Bu, kodunuzu dağınık hale getirecektir (bazı LINQ kod, bazı SQL kod ve / veya DB kaynak kontrolü dışında).
• Herhangi bir soyutlama, kaputun altında nasıl çalıştığını bilmeyen "yüksek seviyeli" geliştiriciler üretebileceğinden

Genel ödünleşim, büyük bir esnekliğe sahip olmak ve çok fazla zaman kaybetmek ve yapabileceğiniz şeyle kısıtlanmak, ancak çok hızlı bir şekilde yapılması arasındadır.

Bu sorunun genel bir cevabı yok. Bu kutsal savaşlar meselesi. Ayrıca elinizdeki bir projeye ve ihtiyaçlarınıza bağlıdır. Sizin için en uygun olanı alın.

sorunuz temelde O / RM ve SQL yazma

ORM veya düz SQL mi kullanıyorsunuz?

Oradaki diğer O / RM çözümlerine bir göz atın, L2S tek değil (NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

belirli soruları yanıtlamak için:

1. O / RM çözümünün kalitesine bağlı olarak, L2S SQL üretmede oldukça iyidir
2. İşlemi gerçekleştirdikten sonra O / RM kullanmak normalde çok daha hızlıdır
3. Kod da genellikle daha temiz ve daha sürdürülebilir
4. Düz SQL elbette size daha fazla esneklik sağlayacaktır, ancak çoğu O / RM en karmaşık sorgular dışında tümünü yapabilir
5. Genel olarak bir O / RM ile gitmenizi öneririm, esneklik kaybı ihmal edilebilir

LINQ-to-SQL, kullanımı çok basit ve büyük ölçüde arka uca çok iyi sorgular üreten dikkate değer bir teknoloji parçasıdır. LINQ-to-EF, yerini almak için planlandı, ancak tarihsel olarak kullanımı son derece tıknazdı ve çok daha düşük SQL üretti. Mevcut durumu bilmiyorum, ancak Microsoft L2S'nin tüm iyiliğini L2EF'e geçireceğine söz verdi, bu yüzden belki de şimdi daha iyi.

Şahsen, RM araçları (benim hiciv bakınız tutkulu bir antipati var burada L2S bana bütün verir beri, L2EF lehine hiç bir neden görmüyorum detaylar için) ve bu yüzden hiç bir veri erişim katmanından ihtiyaca bekliyoruz. Aslında, el yapımı eşlemeler ve kalıtım modellemesi gibi L2S özelliklerinin tamamen gereksiz karmaşıklık getirdiğini düşünüyorum. Ama bu sadece benim. ;-)

Saklı yordamların gücü ve performansı ve Entity Framework gibi araçların sağladığı hızlı geliştirme olup olmadığını düşünmek isteyebileceğiniz yepyeni bir yaklaşım var.

Küçük bir projede test sürüşü için SQL + aldım ve gerçekten özel bir şey. Temel olarak SQL rutinlerinize ne kadar miktarda yorum eklediğinizi ve bu yorumlar bir kod üretecine talimatlar sağlar. Tersine benzer bir varlık çerçevesi.

Girdi parametreleri bir girdi nesnesinin parçası olur, çıktı parametreleri ve sonuç kümeleri bir çıktı nesnesinin parçası olur ve bir hizmet bileşeni yöntem çağrılarını sağlar.

Saklı yordamları kullanmak istiyor, ancak yine de hızlı bir gelişme istiyorsanız, bu şeylere bir göz atmak isteyebilirsiniz.