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

Может и даже работает, но при условии что объект создан при помощи контекста, или в него добавлен. Runtime, насколько я понимаю, подменяет его прокси объектом. Кстати должна быть включена опция: this.ContextOptions.LazyLoadingEnabled = true;

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

HL>public class Nationality
HL>{
HL>}

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

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

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

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

Совершенно верно.

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

Ну тут мне еще self-tracking надо поковырять. Еще не добрался

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

Я тоже так думал, но сгенерированные POCO классы имеют логкику, для поддержания консистенции объектов. Так например при утановки национальности эта логика устанавливает значение FK; старый Nationality Объект теряет ссылку на персону, и в новой национальности устанавливается ссылка на персону Nationality.Person = Person. Эта логика затрагивает контекст и вызвает исключение

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

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

Кстати указанный мною сценарий по установке национальности работает, но сильно смущает. Я сейчас поковыряю self-traking объкты и подумаю как его у себя применить.
Спасибо за ответы