Veritabanını DbContext ile kullanarak Linq-to-SQL'den Entity Framework'e (4.4) geçiş yapıyorum. Ben aşağıdaki davranış normal olup olmadığını merak ediyorum:İlişkileri değiştirdiğimde yabancı anahtar özelliklerini manuel olarak ayarlamalı mıyım?
using (var e = new AgendaEntities()) {
var store = e.Stores.First();
var office = e.Offices.Create();
office.Store = store; // Set association
Console.WriteLine(office.StoreID); // shows Guid.Empty, expected store.ID!
}
L2S yılında da StoreID
anahtarını güncellerdi bir varlığa Store
dernek ayarı. EF'de, bu gerçekleşmiyor gibi görünüyor. Bu, varlıkların yeni olup olmadığına veya bağlamdan yüklendiğine bakılmaksızın geçerlidir.
Ben SaveChanges
, doğru kazandırır ve StoreID
kaydettikten sonra office.ID
eşleşecek şekilde güncellenir, ama neden bu sadece oluyor?
Eksik olduğum bir şey var mı, yoksa şu anda yabancı anahtarları el ile eşitlemeli miyim?
Çözüm Düzenleme: Bu özellik düzeltme denir ve oluşturulan proxy tarafından otomatik yapılması için kullanılır. Ancak, DbContext
ile bu artık geçerli değil. this Connect issue'a göre, bu tasarım gereğidir. Sadece geç yükleme proxy (düzeltme-up yapmayın olan) -
Merhaba, DBContext şablon aslında değişim izleme proxy olarak kullanılacak sınıfları oluşturmaz. Bu kararı aldık çünkü değişiklik izleme proxy'leri karmaşıktır ve geliştiricilere çok kafa karıştırıcı olabilecek çok sayıda nüansa sahiptir. SaveChanges'ten önce düzeltmek istediğinizde myContext.ChangeTracker.DetectChanges'i arayabilirsiniz. ~ EF Ekibi
alternatif varlık senkronize edecek olan DbContext.Entry(entity)
aramak. Bu, bu makalede açıklanan: Relationships and Navigation Properties
Daha fazla insanın bu çözümü takdir etmediğini anlamak çok zor. Kimse dbcontext ile bu şekilde çalışmıyor? – danihp
Şahsen, şimdi dernekleri değiştirdiğimde anahtarları manuel olarak ayarlıyorum. Düzeltme işi iyi bir fikirdi, ancak bazı düşüncelerden sonra POCO'ların bunu yapmasını beklemek pek mantıklı değil. Dernekleri değiştiren tüm işlemler, bazı etki alanı katmanı yöntemlerinde yine de soyutlanmalıdır, bu nedenle sonuçta düşündüğüm gibi değil. –
Tamamen 'basit' varlıklar için, varlıkları UI katmanına açıklayabilmek için tüm iş kurallarına sahip dbEntityValidations aracılığıyla 'katmanlılar' yapıyorum. Ben "entry.related" ancak detChanges yaklaşımı ile tembellik ile ilgili varlıklarla ilgileniyorum. Gönderiniz ve çözümünüz için teşekkürler. – danihp