EF4 POCO свойство "один ко многим": NULL - PullRequest
Новая
       39

EF4 POCO свойство "один ко многим": NULL

4 голосов
/ 05 января 2010

Я использую VS2010, CTP-функцию EF4 (последний выпуск) и объекты POCO, как в примере ниже: 

class Person
{
 public int ID { get; set; }
 public string Name { get; set; }
 public virtual IList<Account> Accounts { get; set; }
 ...
}

class Account
{
 public string Number { get; set; }
 public int ID { get; set; }
 ...
}

Для краткости предположим, что context ниже - это контекстный объект для EF4. У меня есть dbml-сопоставление между типами сущностей и базой данных, и я использую его без проблем: 

Person doug = context.Persons.CreateObject();
doug.Name = "Doug";    
context.Add(doug);
context.Save();
doug.Accounts.Add(new Account() { Name = "foo" });
context.Save(); // two calls needed, yuck

На данный момент в базе данных есть запись Person с именем «Doug» и запись учетной записи «foo». Я могу запросить и вернуть эти записи просто отлично. Но если я вместо этого попытаюсь добавить учетную запись до , я сохраню Person, список учетных записей будет нулевым (прокси еще не создал экземпляр для этого свойства). Смотрите следующий пример: 

Person doug = context.Persons.CreateObject();
doug.Name = "Doug";
doug.Accounts.Add(new Account() { Name = "foo" }); // throws null reference exception
context.Add(doug);
context.Save();

Кто-нибудь еще сталкивался с этим? Еще лучше, кто-нибудь нашел хорошее решение?

Ответы [ 3 ]

3 голосов
/ 22 ноября 2010 
Person doug = context.Persons.CreateObject();

doug.Name = "Doug";

context.Add(doug);
doug.Accounts.Add(new Account() { Name = "foo" });
context.Save();

Это будет работать

2 голосов
/ 06 января 2010

Да и да!

Когда вы добавляете POCO вверх (в отличие от CreateObject из контекста), прокси для вас не предоставляются.Это может показаться очевидным, но я должен был явно напомнить себе об этом поведении, когда преследовал похожую проблему.(Я знаю, что это не та ситуация, которую вы описали в этом вопросе, но общая проблема должна быть подтверждена).

Инициализация коллекций в конструкторе POCO не мешает правильному поведению отложенной загрузки прокси-сервера EF4,из того, что я наблюдал в моем собственном тестировании.

Хорошо, все это, как говорится, теперь я вижу ваш комментарий к предыдущему ответу - почему у меня нет проксированной коллекции адресов, когда я запрашиваю новуюЧеловек из моего контекста?У вас включена отложенная загрузка в контексте?Видя, как мы имеем дело со свойствами навигации, я понял, что отключение отложенной загрузки может изменить ситуацию.

1 голос
/ 05 января 2010

ISTM, что если вы ожидаете, что фреймворк сделает все это за вас, то у вас не будет "POCO", не так ли? Возьмите свой Person класс, с кодом выше. Каково было бы ожидать состояние свойства Accounts после создания без конструктора, если бы EF не был задействован? Сдается мне, что CLR гарантирует их нулевое значение.

Да, прокси-серверы могут инициализировать это при необходимости для материализации значений БД, но в EF «POCO» фактически означает « Обычный ». Не «что-то упакованное сгенерированным во время выполнения кодом, которое мы притворяемся,« Простое »».

...