2013-03-21 21 views
9

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

+0

Daha fazla insanın bu çözümü takdir etmediğini anlamak çok zor. Kimse dbcontext ile bu şekilde çalışmıyor? – danihp

+0

Ş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. –

+0

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

cevap

6

sayılı Varlık çerçeve sizin için yapar "FKS ve Navigasyon özellikleri arasındaki değişiklikleri senkronize" altında. Daha fazla bilgi için Relationships and Navigation Properties'u okuyun. Bir navigasyon özelliğine yeni bir nesne atayarak

. Aşağıdaki kodu, bir kurs ve department arasında bir ilişki oluşturur. nesneler içeriğe bağlı ise, course da department.Courses koleksiyona eklenmiştir ve tabii ki bir nesne üzerinde karşılık gelen yabancı anahtar özelliği department arasında önemli özellik değerine ayarlanır.

  • course.Department = department;

Ama gözlenen gibi SaveChanges veya "FKS ve Navigasyon özellikleri arasındaki değişiklikleri senkronize etme" bölümünde belirtilen diğer eylemlerden birini çağırdıktan sonra, bu yalnızca olur yukarıda bağlanmış belgenin.size yakınlık olmadan POCO varlıkları kullanıyorsanız

, sen DetectChanges yöntemi bağlamında ilgili nesneleri senkronize etmek denir emin yapmalısınız. Aşağıdaki API'lerin otomatik olarak , bir DetectChanges çağrısını tetiklediğini unutmayın.

  • DbSet.Add
  • DbSet.Find
  • DbSet.Remove
  • DbSet.Local
  • DbContext.SaveChanges
  • DbSet.Attach
  • DbContext.GetValidationErrors
  • DBContext. Giriş
  • DbChangeTracke bu her de olmamasını ise r.Entries
  • bir DbSet

karşı LINQ sorgusu yürütme, benim tahminim düzgün navigasyon özelliğinin yabancı anahtar olarak StoreID tanımlanmamış olmasıdır Store.

+1

Sanırım, bağlandığınız makalenin altındaki "FK'ler ve Gezinme özellikleri arasındaki değişiklikleri senkronize etme" bölümünde anlatılanlar açıklanmaktadır. 'E.Entry (office)' i çağırmak kimlikleri senkronize eder. Ancak, hata ayıklayıcısında proxy'lerin oluşturulduğunu görebiliyorum, bu yüzden * çalışması * –

+0

@IliaJerebtsov ahh do correctgru. Başta soruyu yanlış anladım. Hiç olmadığını söylemiştin sanıyordum. –

+0

Teşekkürler, ben bunu dbContext API'sinde tasarım gereği fixup eksikliği olduğunu anladım. –