Entity Framework ve LINQ'dan SQL'e

Artık .NET v3.5 SP1 (VS2008 SP1 ile birlikte) piyasaya sürüldüğüne göre, artık .NET varlık çerçevesine erişimimiz var.

Sorum şu. Entity Framework ile LINQ to SQL'i ORM olarak kullanma arasında karar vermeye çalışırken, fark nedir?

Anladığım gibi, Entity Framework (LINQ to Entities ile birlikte kullanıldığında) LINQ to SQL'in 'ağabeyi' mi? Bu durumda - ne gibi avantajları var? LINQ to SQL'in kendi başına yapamadığı ne yapabilir?

LINQ to SQL, yalnızca Microsoft SQL Server'da bulunan veritabanı tabloları, görünümler, sprocs ve işlevlerin 1'e 1 eşlenmesini destekler. Nispeten iyi tasarlanmış SQL Server veritabanlarına hızlı veri erişimi oluşturmak için harika bir API. LINQ2SQL ilk olarak C # 3.0 ve .Net Framework 3.5 ile piyasaya sürüldü.

LINQ to Entities (ADO.Net Entity Framework), nesne etki alanı modellerinin ve bunların birçok farklı ADO.Net veri sağlayıcısıyla ilişkilerinin geniş bir tanımlamasına izin veren bir ORM (Nesne İlişkisel Eşleyici) API'sıdır. Bu nedenle, çeşitli tablolar, kaynaklar, hizmetler, vb. .Net Framework 3.5 SP1.

Bu MSDN hakkında iyi bir tanıtım makalesi: İlişkisel Verilere LINQ Tanıtımı

Bence hızlı ve kirli cevap

• LINQ to SQL bunu yapmanın hızlı ve kolay yoludur. Bu, daha hızlı gideceğiniz ve daha küçük bir şey üzerinde çalışıyorsanız daha hızlı teslim edeceğiniz anlamına gelir.
• Varlık Çerçevesi, bunu yapmanın her şeyi barındıran, engelsiz bir yoldur. Bu, daha fazla zaman harcayacağınız, daha yavaş geliştireceğiniz ve daha büyük bir şey üzerinde çalışıyorsanız daha fazla esnekliğe sahip olacağınız anlamına gelir.

LINQ to SQL Gerçekten Ölü mü? Jonathan Allen tarafından InfoQ.com

Matt Warren, [LINQ'dan SQL'e], "asla var olması bile gerekmeyen" bir şey olarak tanımlar. Aslında, gerçek ORM hazır olana kadar LINQ geliştirmelerine yardımcı olmak için sadece stand-in olması gerekiyordu.

...

Entity Framework ölçeği, .NET 3.5 / Visual Studio 2008 son tarihini kaçırmasına neden oldu. Ne yazık ki, bir hizmet paketinden çok büyük bir sürüm gibi görünen ".NET 3.5 Service Pack 1" için zamanında tamamlandı.

...

Geliştiriciler karmaşıklık nedeniyle [ADO.NET Entity Framework] ürününü sevmiyor.

...

.NET 4.0 itibariyle, LINQ to Entities ilişkisel senaryolara LINQ için önerilen veri erişim çözümü olacaktır.

@Lar'ın yayınladığı makalede ana hatlarıyla belirtilen bir takım belirgin farklılıklar vardır, ancak kısa cevap şöyledir:

• L2S sıkıca bağlandı - belirli bir veritabanı alanına nesne özelliği veya belirli bir veritabanı şemasına daha doğru nesne eşlemesi
• L2S sadece SQL Server ile çalışacaktır (bildiğim kadarıyla)
• EF, tek bir sınıfı birden çok tabloyla eşlemeye izin verir
• EF MM ilişkilerini ele alacak
• EF, herhangi bir ADO.NET veri sağlayıcısını hedefleme yeteneğine sahip olacaktır

Orijinal öncül L2S Hızlı Geliştirme için, EF daha "girişimci" n katmanlı uygulamalar için, ama bu L2S biraz kısa satıyor.

SQL'den LINQ

1. Homojen veri kaynağı: SQL Server
2. Yalnızca veri yapısının iyi tasarlandığı küçük projeler için önerilir
3. Eşleme, SqlMetal.exe ile yeniden derlenmeden değiştirilebilir
4. .dbml (Veritabanı İşaretleme Dili)
5. Tablolar ve sınıflar arasında bire bir eşleme
6. TPH mirasını destekler
7. Karmaşık türleri desteklemez
8. Önce depolama yaklaşımı
9. Bir veritabanının veritabanı merkezli görünümü
10. Oluşturan C # team
11. Desteklenen ancak daha fazla geliştirilmemesi amaçlanan

Varlık Çerçevesi

1. Heterogeneus veri kaynağı: Birçok veri sağlayıcısını destekler
2. Aşağıdakiler hariç tüm yeni projeler için önerilir:
   • küçük olanlar (LINQ to SQL)
   • veri kaynağı düz bir dosya olduğunda (ADO.NET)
3. Model ve dosya eşlenirken eşleme yeniden derleme yapılmadan değiştirilebilir Meta Veri Artefakt Süreci Çıktı Dizine Kopyala
4. Şunları içeren .edmx (Varlık Veri Modeli):
   • SSDL (Depolama Şeması Tanımlama Dili)
   • CSDL (Kavramsal Şema Tanımlama Dili)
   • MSL (Eşleme Belirtimi Dili)
5. Tablolar ve sınıflar arasında bire bir, bire çok, çoktan bire eşlemeler
6. Kalıtsallığı destekler:
   • TPH (Hiyerarşi Başına Tablo)
   • TPT (Tür Başına Tablo)
   • TPC (Beton Sınıfı Başına Masa)
7. Karmaşık türleri destekler
8. Önce kod, Önce model, Önce depolama ilkesi yaklaşımları
9. Veritabanının uygulama merkezli görünümü
10. SQL Server ekibi tarafından oluşturuldu
11. Microsoft Veri API'lerinin Geleceği

Ayrıca bakınız:

• LINQ to SQL Vs Entity Framework
• LINQ to SQL ve Entity Framework arasındaki fark
• Varlık Çerçevesi vs LINQ TO SQL

Entity Framework ile yaşadığım deneyim yıldızdan daha az oldu. İlk olarak, EF temel sınıflarından miras almalısınız, bu yüzden POCO'lara güle güle deyin. Tasarımınızın EF etrafında olması gerekir. LinqtoSQL ile mevcut iş objelerimi kullanabilirim. Ayrıca, tembel yükleme yoktur, bunu kendiniz uygulamanız gerekir. POCO'ları ve tembel yüklemeyi kullanmak için etrafta bazı çalışmalar var, ancak EF henüz hazır olmadığı için IMHO var. 4.0'dan sonra tekrar gelmeyi planlıyorum

Burada , basit kelimelerde ne zaman kullanılacağını açıklayan çok iyi bir cevap buldum :

Hangi çerçevenin kullanılacağının temel kuralı, sunum katmanınızdaki verilerinizi düzenlemeyi nasıl planlayacağınızdır.

• Linq To-SQL - sunum katmanınızdaki verilerinizin bire bir ilişkisini düzenlemeyi planlıyorsanız bu çerçeveyi kullanın. Yani herhangi bir görünümde veya sayfada birden fazla tablodan veri birleştirmeyi planlamıyorsunuz.

• Varlık Çerçevesi - görünümünüzde veya sayfanızda birden fazla tablodan veri birleştirmeyi planlıyorsanız bu çerçeveyi kullanın. Bunu daha açık hale getirmek için, yukarıdaki terimler yalnızca görüntülenmekle kalmayıp görünümünüzde veya sayfanızda değiştirilecek verilere özeldir. Bunu anlamak önemlidir.

Varlık Çerçevesi ile düzenlenebilir bir biçimde sunu katmanına sunmak için tablolanmış verileri bir araya getirebilir ve daha sonra bu form gönderildiğinde EF çeşitli tablolardaki TÜM verileri nasıl güncelleyeceğini bilecektir.

L2S yerine EF'i seçmek için muhtemelen daha doğru nedenler vardır, ancak bu muhtemelen anlaması en kolay olanı olacaktır. L2S, görünüm sunumu için verileri birleştirme özelliğine sahip değildir.

Benim izlenim, Linq2Sql ihtiyaçlarınızı karşılamıyorsa, veritabanınızın oldukça muazzam veya çok kötü tasarlanmış olmasıdır. Linq2Sql kullanan hem daha büyük hem de daha küçük yaklaşık 10 web sitem var. Varlık çerçevesine birçok kez baktım ama Linq2Sql üzerinde kullanmak için iyi bir neden bulamıyorum. Veritabanlarımı model olarak kullanmaya çalıştığımı söylediğim için model ve veritabanı arasında zaten 1'e 1 eşleme var.

Şu anki işimde 200'den fazla tablo içeren bir veritabanımız var. Birçok kötü çözüm içeren eski bir veritabanı var, bu yüzden Linq2Sql üzerinde Entity Framework avantajını görebiliyordum ama yine de veritabanını uygulamanın altyapısı olduğu için veritabanını yeniden tasarlamayı tercih ediyorum ve veritabanı kötü tasarlanmış ve benim uygulamadan sonra yavaş olacaktır. Böyle bir veritabanında Entity çerçevesinin kullanılması, kötü modeli gizlemek için bir hızlı düzeltme gibi görünür, ancak böyle bir veritabanından aldığınız kötü performansı asla gizleyemez.

Burada iyi bir karşılaştırma bulabilirsiniz:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

Buradaki yanıtlar Linq2Sql ve EF arasındaki farkların çoğunu kapsıyordu, ancak çok fazla dikkat edilmeyen bir anahtar nokta var: Linq2Sql sadece SQL Server'ı desteklerken EF'nin aşağıdaki RDBMS'leri sağlayıcıları var:

Microsoft tarafından sağlanmıştır:

• ADO.NET için sürücüler için SQL Server, OBDC ve OLE DB

Üçüncü taraf sağlayıcılar aracılığıyla:

• MySQL
• torpil
• DB2
• VistaDB
• SQLite
• PostgreSQL
• ınformix
• U2
• Sybase
• Synergex
• Firebird
• Npgsql

birkaç isim.

Bu, EF'i ilişkisel veri deponuz üzerinde güçlü bir programlama soyutlaması yapar, yani geliştiricilerin temel veri deposundan bağımsız olarak çalışmak için tutarlı bir programlama modeli vardır. Bu, geniş bir yelpazedeki yaygın RDBMS'lerle birlikte çalışmasını sağlamak istediğiniz bir ürün geliştirdiğiniz durumlarda çok yararlı olabilir.

Bu soyutlamanın faydalı olduğu diğer bir durum da, bir dizi farklı müşteriyle veya bir kuruluştaki farklı iş birimleriyle çalışan bir geliştirme ekibinin parçası olduğunuz ve olması gereken RDBMS'lerin sayısını azaltarak geliştirici verimliliğini artırmak istediğinizdir. farklı RDBMS'lerin üzerinde bir dizi farklı uygulamayı desteklemek için

EF kullanırken aynı veritabanı modeli içinde birden fazla veritabanı kullanamadığımı fark ettim. Ancak linq2sql'de şema adlarını veritabanı adlarıyla önek olarak ekleyebilirim.

Başlangıçta linq2sql ile çalışmaya başlamamın nedenlerinden biri de buydu. EF'in bu işlevselliğe henüz izin verip vermediğini bilmiyorum, ancak buna izin vermemenin amaçlandığını okuduğumu hatırlıyorum.

Veritabanınız basit ve basitse, LINQ to SQL bunu yapacaktır. Tablolarınızın üstünde mantıksal / soyutlanmış varlıklara ihtiyacınız varsa, Entity Framework için gidin.

İkisi de benzersiz SQL 2008 veri tiplerini desteklemiyor. Benim bakış açımdan farkı, Entity'nin gelecek veri sürümlerinde coğrafi veri tipim etrafında bir model oluşturma şansı olması ve Linq to SQL'den vazgeçilmesi asla olmayacak.

NHibernate veya OpenAccess ile neler olduğunu merak edin ...

Ortada garip bir şey olmadan hızlı bir şey geliştirmeniz gerekiyorsa ve tablolarınızı temsil eden varlıklara sahip olmak için tesise ihtiyacınız varsa:

Linq2Sql iyi bir müttefik olabilir, LinQ ile kullanmak büyük bir geliştirme zamanlaması ortaya çıkarır.

Linq-to-SQL kullanan büyük bir projesi olan müşteri için çalışıyorum. Entity Framework o sırada bazı önemli özelliklerden yoksun olduğu ve Linq-to-SQL'in performansı çok daha iyi olduğu için proje başladığında bu bariz bir seçimdi.

Şimdi EF evrim geçirdi ve Linq-to-SQL, yüksek düzeyde ölçeklenebilir hizmetler için harika olan zaman uyumsuz desteğe sahip değil. Bazen saniyede 100'den fazla isteğimiz var ve veritabanlarımızı optimize etmemize rağmen, çoğu sorgunun tamamlanması birkaç milisaniye sürüyor. Senkronize veritabanı çağrıları nedeniyle, iş parçacığı engellenir ve diğer istekler için kullanılamaz.

Yalnızca bu özellik için Varlık Çerçevesine geçmeyi düşünüyoruz. Microsoft'un Linq-to-SQL'e zaman uyumsuz destek uygulamadığı (ya da topluluğun bunu yapabilmesi için utanç verici) bir utanç.

Ek Aralık 2018: Microsoft, .NET Core'a doğru ilerliyor ve Linq-2-SQL, .NET Core'da desteklenmediğinden, gelecekte EF.Core'a geçebildiğinizden emin olmak için EF'e taşınmanız gerekir.

LLBLGen gibi dikkate alınması gereken başka seçenekler de vardır . Zaten uzun süredir var olan ve MS veri çözümlerinden (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core) daha fazla kanıtlanmış olgun bir ORM çözümüdür.

Linq SQL

Yalnızca SQL Server'ı desteklediği sağlayıcıdır. SQL Server veritabanı tablolarını .NET nesnelerine eşlemek için kullanılan bir eşleme teknolojisidir. Microsoft'un bir ORM - Nesne İlişkisel Eşleştiricisi'nde ilk denemesi.

Linq varlıkları

Aynı fikir, ama arka planda Entity Framework kullanarak, ORM olarak - yine Microsoft'tan, Varlık çerçevesinin çoklu avantajını destekleyen Varlık çerçevesinin ana avantajı geliştirici, farklı veritabanlarında herhangi bir işlem gerçekleştirmek için sözdizimi öğrenmeye gerek yok herhangi bir veritabanı üzerinde çalışabilir

Kişisel tecrübelerime göre Ef, daha iyi (SQL hakkında hiçbir fikriniz yoksa) LINQ'daki performans, lambda ile yazılmış EF neden LINQ diliyle karşılaştırıldığında biraz daha hızlıdır.