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

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

S>>Зависит от условий задачи: дата рождения, место жительства, серия + номер паспорта и т.д. и т.п.

D>Ну вот видите — указателей/ссылок, даже в элементарном сферовакуумном примере, недостаточно для эффективного обеспечения identity объектов.
Надо различать две задачи: идентификацию самих объектов предметной области, и идентификацию экземпляров классов в ООП. Идентификация объектов предметной области — широкая и местами сложная тема, в которой надо плясать в основном от требований к приложению. Идентификация экземпляров — вещь очень простая: у каждого объекта в памяти есть адрес, в дотнете можно сравнивать объекты на ссылочное равенство (ReferenceEquals). Суррогатные ключи в базе данных — это аналог адреса объекта для базы — нужен для удобного обращения к определенной строке таблицы. Строго говоря, primary key необходим ОРМ-у внутри себя для обеспечения identity mapping, а также для сохранения/удаления объектов в/из базы. То свойство/поле с первичным ключом, которое содержится в объекте — это не более чем копия настоящего значения primary key, и для ОРМ его наличие не играет особой роли. Если бы это было не так, ОРМ не смог бы обеспечить правильность работы при изменении пользователем первичного ключа в объекте. То есть наличие в объекте свойства Customer.CustomerID — это опция для удобства и для обеспечения возможности обращаться к primary key объекта из LINQ2Entity.

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

D>Ничего подобного. Пользователь может его в виде компоненты http-ссылки наблюдать, например. А уж собственно потрохам приложения PK так и вообще на каждом шагу необходим...
Ну это правильно, но вынужденно, т.к. для URL необходим текстовый аналог уникальной ссылки на объект, и использовать для этого данные предметной области неудобно.