Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, henson, Вы писали:

H>>>>В EF кое-что могло бы быть упрощено если бы EntityObject уже содержал некий общий Id который все равно нужен в каждом дочернем объекте.
G>>>EntityKey?

H>>EntityKey все-таки не поле в базе данных, а объект хранящий ссылку на ключевое поле, т.е. какой-то дополнительный Id ВСЕГДА нужен
G>Неверно. http://msdn.microsoft.com/ru-ru/library/system.data.entitykey(VS.90).aspx

Что именно неверно? Как использовать EntityKey без внешнего ID ?

Здравствуйте, syomin, Вы писали:

G>>2)Сделать свойства private
S>Некошерно. Я же знаю, что они там есть и это претит моему чувству прекрасного.

Тогда лучше начать с исправления этого самого чувства.

Товарищ конечно жестковато ответил, но по сути он прав. Закос данных под полноценные ОО-объекты (даже звучит смешно) — это чистейшая профанация.

Данные есть данные. И в объекты ты их кладешь только потому, что так удобнее получить доступ к этим самым данных в твоем любимом языке.

Здравствуйте, syomin, Вы писали:

S>Первичный ключ используется базой данных для однозначной идентификации строки в таблице. Поскольку задача ORM'а состоит в том, чтобы изолировать объекты предметной области от базы данных,

Не читайте Фаулера перед обедом.

"изолировать объекты предметной области от базы данных" — это задача Object Persistence Framework-ов, а не ORM. Задача ORM же намного проще — преобразовать реляционные данные (записи из таблиц) в списки объектов, тем самым упростив их обработку в ООЯ.

Так вот, Persistence Framework-и приводят к неоправданному оверхэду, при этом не давая реального повышения уровня абстрации.

S>то перечисленных выше полей быть не должно — достаточно просто ссылок. Думаю, технически это возможно. Другое дело, возможно ли это в EF.

Если тебе нужен Persistence Framework, то лучше выбрать Hibernate. Только потом не надо задавать вопрос "почему моё приложение так тормозит?".

G>>Потом сжечь все книги по ООП и выкинуть фаулера АКПП.
S>Не конструктивно.

Последнее как раз конструктивно. Первое, конечно, перебор. Но вот доверять всему чему пишут в ООП-книгах нужно с оглядкой. ООП не панацея. Где-то он отлично ложится на задачу. Где-то он просто вреден или менее удобен.

Для обработки данных хранящихся в СУБД лучше подходит функциональный подход, а не ООП.

Здравствуйте, syomin, Вы писали:

D>>Ну и как Ваш пользователь будете различать сотрудников у которых полностью одинаковые ФИО ?
S>Зависит от условий задачи: дата рождения, место жительства, серия + номер паспорта и т.д. и т.п.

Это называется "составной первичный ключ".

S> Поймите простую вещь: если у нас первичный ключ является суррогатным, то в большинстве случаев никакого смысла показывать его пользователю нет, поэтому и тащить его в приложении дальше слоя доступа к базе данных не нужно.

А зачем пользователю то показывать? Скрывай его. Но в той же форме его держать надо, чтобы потом было по чему обновлять данные. (Хотя я не раз видел как люди запоминали свои номера и потом быстро по ним идентифицировались.)

Смотри какая фигня получается. Скрыв идентификатор в объекте и пытаясь идентифицировать что-то самим экземпляром объекта ты будешь вынужден сделать объект уникальным. Это резко усложняет работу с ним. Ты вынужден гарантировать, что данные в этом объекте синхронны данным в БД и то, что объект один. Это же означает, что такой же объект в другом процессе уже заводить чревато.

Здравствуйте, syomin, Вы писали:

G>>Ну тогда тебе остается только свой ORM писать, покажи потом что получилось.
S>Проще победить чувство прекрасного...

Если действительно достаточно загрузить сразу в память все данные, покрутить их там и сбросить на диск, то вам ни ОРМ ни БД даром не нудны: созраняйте в бинарник или в хмл на диск. Если нужна БД, то такой "ОРМ" делается за пол-дня/день, что совсем не дорого На крайняк можно в той же БД хранить граф в хмл. В таком случае просто EF — это молоток в ситуации, когда нужны пасатижы (здесь).

А вот как только [если] вам понадобится не "целый граф", а постепенное вытягиание сущностей, сохранение с обновлением, а не перезаписыванием, то иметь в какой-либо форме ижентификатор в объекте, с которым происходит работа пользователя придётся.