SQL Server Veri Araçları ve Varlık Çerçevesi - burada herhangi bir sinerji var mı?

Linq2Sql kullanarak bir projeden çıkarken, bir sonraki (daha büyük) kişinin Entity Framework'ün kollarına itebileceğinden şüpheleniyorum. Konuyla ilgili bazı okumalar yaptım, ancak bulmayı başaramadığım, SQL Server Veri Araçları ve Entity Framework'ün birlikte nasıl kullanılabileceği / kullanılabileceği hakkında tutarlı bir hikaye.

• Tamamen ayrı düşünülmüşler miydi ve birlikte kullanmak yanlış bir şekilde okşuyor mu?
• Bir şekilde tamamen dik mi?

İkisini de isteyebileceğimi düşündüğüm bazı nedenler:

• SSDT, 'derlenmiş' (işaretli) ve kolayca sürümlendirilebilir sql ve şemaya sahip olmak için mükemmeldir
• Ancak SSDT 'göç / güncelleme' hikayesi (bana göre) ikna edici değil: "Herhangi bir şeyi güncelle" şema için işe yarıyor, ancak veri için çalışabileceği bir yol yok (AFAIK).
• Öte yandan, EF göçünü benzer sorunlar gösterip göstermediğini öğrenmek için denemedim, ancak Yukarı / Aşağı bitleri oldukça kullanışlı görünüyor.

Başka bir bakış açısı getireyim. Entity Framework Veritabanı Bakımı, herhangi bir işletme veya büyük veritabanı projesinde tamamen işe yaramaz.

Sorunlar:

• Otomatik şema güncellemeleri. Tamamen veritabanı bakım temellerini ihlal gibi kesinlikle bu istediğim değil. Sorunlar şunlardır: (a) daha yeni bir sürüm çalıştıran biri, bir sorun almak yerine veritabanını günceller ve (b) güncellemeler normalde İLK yedek alan dba ile planlanır. Yani, otomatik güncellemeler işe yaramaz.

• DB oluşturma yalnızca temelde dejenere kenar durumlarda çalışır. Hangisi ne olursa olsun gelişmiş veritabanı özelliklerini kullanmaya bile çalışmayın. SQL sunucusu örneği: dizinlerde alanlar, dizinlerde filtreler, bölümleme, sıkıştırma, alanlar için doğrulama kuralları.

• Geçiş - yine dejenere son vakaları varsayar: veri dönüşümü veya çok aşamalı güncelleme kolay değildir. Örnek: Tablo X, kullanıcının bir şey yaptığını kaydeden geçmiş bir "kullanıcı" alanına sahiptir. Yeni kurulumda bir Kullanıcı tablosu vardır, bu nedenle kullanıcı tablosunu oluşturmanız, ardından kullanıcıları oluşturmanız, ardından tablo x'de kullanıcı referans alanını oluşturmanız, ardından bunu kullanıcı tablosundan olduğu kullanıcıyla güncellemeniz ve daha sonra kullanıcı alanını silmeniz gerekir.

Bu senaryolarla başa çıkmanın tek mantıklı yolu, üretim ve geçiş komut dosyaları ve uygun sürüm oluşturmadır.

Şimdi, SSDT - belirli bir veritabanı sürümünü Entity Framework'ten çok daha iyi sürümlemek için harika bir araçtır çünkü gerçekten işe yarıyor. İçinde olduğu gibi: tüm özellikleri kaydeder. Sahip olduğum veritabanlarının hiçbirinde hemen hemen ilk kodu kullanabiliriz - çünkü her zaman en azından dizinleri filtreledik;) EF bile ihtiyacım olanın% 10'una bile ulaşamazdı.

Yaklaşımımız:

• Veritabanındaki veritabanını tasarlayın, ardından teslim alınan bir SSDT modülüyle eşitleyin. Şema eşitlemesi, geliştiricilerin sürümlerini hızlı bir şekilde güncellemelerine olanak tanır. Her zaman geçerli sürümü bir yerde (özel bir sunucuda) yetkili bir ana veritabanı vardır, bu yüzden üzerinde çalışmak için bir referans sürümümüz vardır.

• Sürümlendirilen ve bunları bir veritabanına dağıtmak için güzel bir mekanizmaya sahip sürümler için gerektiği şekilde delta komut dosyaları oluşturun.

EF'i bir SQL Server veritabanı ile kullanmanın birden fazla yolu vardır.

1. Önce Kod ... Sınıflar yazarsınız ve EF ilişkili tabloları oluşturur
2. Önce Veritabanı ... Tabloları tasarlarsınız ve EF sınıfları oluşturur.

EF sizin için tüm işleri yapmayabilir. EF sizi yüzde 80 ila 95 oranında oraya götürür. Veritabanı geliştirme çalışmalarınızın diğer yüzde 5 ila 20'si Görünümler ve Saklı Yordamlar gibi optimizasyonlarla desteklenecektir.

Yani hayır, dik değiller. Ancak, genel tasarım stratejinizin ne olacağına karar vermeniz ve ardından EF'in ideal sonuçlardan daha az ürettiği parçaları optimize etmenize yardımcı olması için SSDT gibi araçlara güvenmeniz gerekir.