Здравствуйте, Аноним, Вы писали:

А>Нарвался на проблему, что LazyLoad не работает с объектами, у которых DataContext уничтожен
О каком LazyLoad может идти речь при использовании POCO?

А>Теперь допустим у Person есть Nationality поле, которое я хочу обновить. Nationality соответствует одноименной таблице и находится в связи А>с Person. Если я меняю значение поля, вываливается ошибка в сгенерированном коде в методе FixupNationality, что DataContext уничтожен
Т.е. есть POCO вида:

public class Nationality
{
}

public class Person
{
  public Nationality Nationality { get; set; }
}

и при выполнении кода на клиенте:

person.Nationality = new Nationality { ... };

вы получаете ошибку?

А>В общем вопросы следующего характера:
А>- нормально ли то что я работаю с POCO объктом без сохранения DataContexta
Да.
Упрощенно, работа с POCO в n-tier строится по такому сценарию:
1. В сервисе вытащили из базы граф объектов и вернули его клиенту (соответственно, выбросили контекст и, следовательно, отсоединили от него полученный граф).
2. На клиенте выполнили изменения, которые граф объектов запомнил (self-tracking).
3. Вернули граф объектов на сервер и одали его вновь созданному контексту.
4. Контекст сам, на основании сохраненных изменений в графе, выполняет присоединение объектов к контексту, меняет их состояние в контексте и сохраняет изменения.
5. Опционально граф объектов отправляется обратно клиенту (с обновленными значениями identity и calculated свойств).

А>- нормально ли то что для изменения такого поля как Nationality я должен пересоздавать DataContext (ведь я же не использую DataContex при изменении например имени). Смущает концепция.
По идее, вы меняете Nationality на клиенте. Там контекста вообще нет и он там на фиг не нужен.
Либо я вас не понял.

А>- может быть стоит отказаться от генерированных классов или модифицировать генерация, что бы исключить проверку консистенции данных
Отказаться от генерации можно, если модель очень простая. В противном случае руками писАть очень много.
Association fixup — штука тоже полезная и тоже избавляет от ручной работы.
Идеальный готовый кодогенератор пока не встретился. Может, хреново искал.

А>- может я вообще неправильно подошел и надо хранить ссылку на DataContext (правда тогда совершенно непонятно можно работать с ним в n-tier сценариях)
См. список выше.
Нет, DataContext хранить не нужно. Выполнили свой unit of work (считали/записали граф) — выбросили контекст.