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

А>Может и даже работает, но при условии что объект создан при помощи контекста, или в него добавлен
Речь шла о графе объектов, который уже передан клиенту. Там контекста нет. И lazy loading нет.
Зачем lazy loading на сервисе, при построении графа, который будет отправляться за пределы этого сервиса, я х.з.
Обычно метод сервиса, которому нужно отдать граф, четко знает, что и на какую глубину загружать. Хотя, может быть, я не сталкивался с такими сценариями.

А>Совершенно верно.
А>Ну тут мне еще self-tracking надо поковырять. Еще не добрался
А>Я тоже так думал, но сгенерированные POCO классы имеют логкику, для поддержания консистенции объектов. Так например при утановки национальности эта логика устанавливает значение FK; старый Nationality Объект теряет ссылку на персону, и в новой национальности устанавливается ссылка на персону Nationality.Person = Person. Эта логика затрагивает контекст и вызвает исключение
Использование POCO нужно для persistence ignorance.
Наличие в коде POCO какой-либо ссылки на сборки EF — это нарушение persistence ignorance, которое лишает смысла использование POCO.
Association fixup в коде POCO ("логика для поддержания консистенции объектов") — это нормально.
Association fixup в коде POCO, использующий контекст — это странно.
Я не смотрел на шаблоны, которые вы используете. Но, если они действительно генерируют fixup-код с использованием контекста, выбростье их.

А>Кстати указанный мною сценарий по установке национальности работает, но сильно смущает.
Еще бы. Ведь вы фактически выполняете руками то, что контекст должен делать автоматически.
Суть self tracking — объект хранит минимально-необходимую информацию о своих изменениях, а контекст умеет этой информацией правильно пользоваться.
Посмотрите хотя бы на те шаблоны, которые идут вместе со студией.