Entity Framework Core 3.0’da birçok önemli değişiklik

W

Womanne

Member


  1. Entity Framework Core 3.0’da birçok önemli değişiklik

Entity Framework Core 3.0’ın aşağıda bahsedilen yeni özelliklerden hiçbirini bulamayacağınız dördüncü bir ön izleme sürümü var. Aksine, Microsoft önemli sayıda önemli değişikliği entegre etti. Soru neden?


Microsoft, Entity Framework Core 3.0 için önemli işlevsel iyileştirmeler duyurdu:

  • Daha iyi LINQ’dan SQL’e dönüştürme (daha fazla sunucu tarafı sorgusu, yani daha az müşteri değerlendirmesi, yani RAM’de sorguların çalıştırılması, büyük miktarda veri için kabul edilemez olan tam tablo yüklemesi gerektirir)
  • NoSQL desteği ve Cosmos DB sürücüsü
  • C# 8.0 desteği (null yapılabilir referans türleri ve eşzamansız akışlar)
  • Veritabanı görünümlerini sorgu türleri ile tersine mühendislik
Özellik Çantası varlıkları (klasik Varlık Çerçevesinde olduğu gibi N:M soyutlamasını desteklemek için, yani ara tabloların artık nesne modelinde sınıflar olarak var olması gerekmez)

2.0/2.1/2.2 için zaten duyurulmuştu.

Önizleme 4, bu yenilikler olmadan, ancak önemli değişikliklerle birlikte



Son dakika değişiklikleri, 1.x veya 2.x veya 3.0 sürümünden geçtiğimizde hepimizin program kodumuzu değiştirmek zorunda kalacağımız anlamına geliyor.

Önemli değişiklikler listesine bakarsanız, bazı tutarsızlıkların giderildiğini, adlandırma iyileştirmelerini görebilirsiniz ve Microsoft’un şu anda Entity Framework Core’da diğer özellikleri kullanıma sunmaya hazırlandığı durumlar vardır.
Davranış değişikliği örneği Geleceğe yönelik bir davranış değişikliği, örneğin, “ToTable() türetilmiş türlerde yayınlamalıdır” şeklindedir. Şimdiye kadar, Entity Framework Core esas olarak Hiyerarşi Tablosu (TPH) devralma stratejisini, bazı durumlarda ayrıca Beton Türü Tablosu’nu (TPCT) da destekler, ancak belgeler aksini belirtir. Entity Framework Core’da “Tür Başına Tablo” (TPT) henüz mevcut değildir. Entity Framework Core 1.x ve 2.x’te, başka bir sınıftan türetilen varlık sınıfları için bile veri açıklamalı açık bir tablo adı kullanmak mümkündü.
veya Fluent API üzerinden Bir masa() Bu varlık sınıfları, TPH ilkesine göre kendi veritabanı tablosuna değil, temel sınıf tablosuna geçirilse bile belirtilir. isimler bir

VEYA
Bir masa() basitçe görmezden gelindiler. Artık Entity Framework Core 3.0’da, Microsoft aniden bir çalışma zamanı hatası veriyor (Yasa Dışı İşlem İstisnası: Yalnızca temel varlık türleri bir tabloya eşlenebilir). Bu, ilk bakışta şaşırtıcı görünebilir, ancak ikinci bakışta anlam netleşir: Microsoft, daha sonraki bir sürümde önkoşullar oluşturmak için bunu kullanmak istiyor.

VE
Bir masa() bir TPT stratejisinin uygulanmasına önem vermek. Semantic Versioning’e göre kırılma değişikliklerine yalnızca ana sürüm numarası değiştirilirken izin verildiğinden, Microsoft şimdi bu davranış değişikliğini sürüm 3.0 ile kullanıma sunuyor; örneğin TPT işlevi de öyle olabilir. 3.1 veya 3.2 sürümünde görünür. Bu değişiklik, hemen görünmeyen yerleri de etkileyebilir. Bir uygulamayı test amacıyla Entity Framework Core 3.0’a zaten taşıdım ve “Geçersiz İşlem İstisnası: Yalnızca temel varlık türleri bir tabloya eşlenebilir” hatasıyla karşılaştım. Açıklamadan sonra Visual Studio’da “Tüm Referansları Bul” yaptım

sınıf veya bir çağrı hakkında Bir masa() fluent api’de sınıfı aradı ama hiçbir şey bulamadı.

#region Bulk configuration via model class for all table names
foreach (IMutableEntityType entity in mb.Model.GetEntityTypes())
{
// All table names = class names (~ EF 6.x),
// except the classes that have a
annotation
varannotation = entity.ClrType?.GetCustomAttribute<TableAttribute>();
if (annotation == null && entity.BaseType == null )
{
entity.Relational().TableName = entity.DisplayName();
}
}
#endregion
Microsoft’un veritabanı tabloları için standart kuralının göz ardı edilmesini sağlayan toplu kurulumumu yalnızca ikinci bakışta düşündüm. Şimdi burada ek koşul


&& varlık.BaseType == boş

  • gerekli:
  • Ad değiştirme örnekleri
  • Yukarıdaki değişiklik yalnızca çalışma zamanında fark edilirken, derleyicinin fark ettiği başka değişiklikler de vardır. Böylece Microsoft bazı isimleri değiştirdi, örneğin:
  • IEntityType.QueryFilter –> GetQueryFilter()
  • IEntityType.DefiningQuery –> GetDefiningQuery()
  • IProperty.IsShadowProperty –> IsShadowProperty()
IProperty.BeforeSaveBehavior –> GetBeforeSaveBehavior()


IProperty.AfterSaveBehavior –> GetAfterSaveBehavior() ForSqlServerHasIndex().ForSqlServerInclude() –> HasIndex().ForSqlServerInclude() performans geliştirmeleri Diğer modifikasyonlar performansı artırmaya yarar. İşte nasıl giriş yapılacağı kayıt()

  • -Yöntem artık bu konuda yok
  • parça değişiklikleri()
  • bağlam sınıfındaki tüm nesneler üzerinde çalışır, ancak yalnızca etkilenen nesne için yerel olarak çalışır ve nesneleri doğrudan atar. Gibi bazı eşzamansız yöntemler için
  • DbContext.FindAsync()
  • DbSet.FindAsync()
DbContext.AddAsync() DbSet.AddAsync() ValueGenerator.NextValueAsync() Microsoft artık bunu bir dönüş türü olarak kullanıyor Görev Değeri yerine Görev öbek üzerindeki bellek ayırma sayısını azaltır. Sınıf Görev Değeri

.NET’te o kadar uzun süredir mevcut değil (yalnızca C# 7.0’dan beri), yalnızca daha önce vardı


Görev

olası.


Neden daha erken değil?



Şimdi bu gönderide Microsoft’un Entity Framework Core’un önceki sürümlerinde bunları neden düşündüğünü veya adların neden doğrudan tutarlı olduğunu soran bir yorumun görüneceğini hayal edebiliyorum. Açıkçası bu daha iyi olurdu, ancak – Entity Framework Core geliştiricilerini özel olarak korumak istemeden – “mükemmel programcı” yoktur. Hepimiz daha sonra düzeltmemiz gereken hatalar yaparız. Hatalarımızı geç düzeltmek hiç düzeltmemekten iyidir.



Microsoft en başından ORM’ye daha fazla işlev eklemiş olsaydı, daha da az önemli değişiklik mümkün olabilirdi. O zaman tasarım hataları doğrudan fark edilirdi. Ancak Entity Framework Core 1.0 çok daha sonra ortaya çıkacaktı. Yazılım geliştirmenin ne kadar çevik olmasını istediğimiz sorusuna geri dönelim.() Haberin Sonu git
 
Cevap yazmak için giriş yap yada kayıt ol.
Üst