D>Поехали по кругу: сие задача всех ORM'ов. То что длительное время люди не могли её внятно сформулировать, и в результате породили таких монстров как Hibernate и EF — это совсем другой вопрос.
Здравствуйте, syomin, Вы писали:
D>>Поехали по кругу: сие задача всех ORM'ов. То что длительное время люди не могли её внятно сформулировать, и в результате породили таких монстров как Hibernate и EF — это совсем другой вопрос.
S>Обратите внимание, что вопрос касается именно EF.
Все известные мне ORMы мапят как минимум первичные ключи на объекты.
Здравствуйте, syomin, Вы писали:
D>>Ну вот видите — указателей/ссылок, даже в элементарном сферовакуумном примере, недостаточно для эффективного обеспечения identity объектов. S>В элементарном сферовакуумном примере для обеспечения идентичности объекта может использоваться связка из гражданства и номера паспорта человека. При этом сделать такой первичный ключ для соответствующей таблицы в БД конечно можно, но неудобно, поскольку составной первичный ключ нельзя использовать для описания внешних ключей.
С чего ты это взял? Все можно.
S>В этом случае делают так: накладывают ограничение уникальности на пару полей "гражданство" и "номер паспорта" и добавляют суррогатный первичный ключ — вещь абсолютно синтетическую, которая нужна только на уровне базы данных и слоя доступа к ней.
Это только соображения удобства.
D>>А уж собственно потрохам приложения PK так и вообще на каждом шагу необходим... S>В описанном случае не нужен. Приложение уже есть и работает, теперь хочется добавить к нему базу данных, чтобы обеспечить персистентность.
Как только объекты начинают "жить" дольше приложения сразу же стандартные средства ООП перестают работать.
D>>>Ну вот видите — указателей/ссылок, даже в элементарном сферовакуумном примере, недостаточно для эффективного обеспечения identity объектов. S>>В элементарном сферовакуумном примере для обеспечения идентичности объекта может использоваться связка из гражданства и номера паспорта человека. При этом сделать такой первичный ключ для соответствующей таблицы в БД конечно можно, но неудобно, поскольку составной первичный ключ нельзя использовать для описания внешних ключей. G>С чего ты это взял? Все можно.
Ссылку можно?
D>>>А уж собственно потрохам приложения PK так и вообще на каждом шагу необходим... S>>В описанном случае не нужен. Приложение уже есть и работает, теперь хочется добавить к нему базу данных, чтобы обеспечить персистентность. G>Как только объекты начинают "жить" дольше приложения сразу же стандартные средства ООП перестают работать.
Ну так и пусть ключи будут в storage model — я же не против. Другое дело, что не очень хочется их в conceptual model тащить...
Здравствуйте, syomin, Вы писали:
S>Приложение уже есть и работает, теперь хочется добавить к нему базу данных, чтобы обеспечить персистентность.
Если у Вас более-менее сложная ООП-style модель данных, при разработке которой не учитывались вопросы сохраняемости, то добавить к такой конструкции "классический" persistence в БД => переписать почти всё что связано с оной моделью.
Вы точно уверены, что Вам именно БД нужна ? Для многих случаев ведь достаточно простейшей "залповой" сериализации всего графа объектов модели данных.
Здравствуйте, syomin, Вы писали:
S>>>поскольку составной первичный ключ нельзя использовать для описания внешних ключей. G>>С чего ты это взял? Все можно. S>Ссылку можно?
Здравствуйте, syomin, Вы писали:
D>>>>Ну вот видите — указателей/ссылок, даже в элементарном сферовакуумном примере, недостаточно для эффективного обеспечения identity объектов. S>>>В элементарном сферовакуумном примере для обеспечения идентичности объекта может использоваться связка из гражданства и номера паспорта человека. При этом сделать такой первичный ключ для соответствующей таблицы в БД конечно можно, но неудобно, поскольку составной первичный ключ нельзя использовать для описания внешних ключей. G>>С чего ты это взял? Все можно. S>Ссылку можно? http://msdn.microsoft.com/en-us/library/ms174979.aspx
< table_constraint > ::=
[ CONSTRAINT constraint_name ]
{
{ PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
(column [ ASC | DESC ] [ ,...n ] )
[
WITH FILLFACTOR = fillfactor
|WITH ( <index_option> [ , ...n ] )
]
[ ON { partition_scheme_name (partition_column_name)
| filegroup | "default" } ]
| FOREIGN KEY
( column [ ,...n ] )
REFERENCES referenced_table_name [ ( ref_column [ ,...n ] ) ]
[ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
[ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
[ NOT FOR REPLICATION ]
| CHECK [ NOT FOR REPLICATION ] ( logical_expression )
}
Выделенное то что тебе нужно.
D>>>>А уж собственно потрохам приложения PK так и вообще на каждом шагу необходим... S>>>В описанном случае не нужен. Приложение уже есть и работает, теперь хочется добавить к нему базу данных, чтобы обеспечить персистентность. G>>Как только объекты начинают "жить" дольше приложения сразу же стандартные средства ООП перестают работать. S>Ну так и пусть ключи будут в storage model — я же не против. Другое дело, что не очень хочется их в conceptual model тащить...
Еще раз, не все сценарии бизнес-логики и даже UI возможны только на ссылках, потому что их время жизни гораздо меньше времени жизни "объектов".
То что ты написал программу так, что таких сценариев, нет никого не интересует, завтра у тебя появится такой сценарий и придется тащить везде ключи.
Поэтому производители ORM, несмотря на "чувство прекрасного", которое противоречит здравому смыслу, всетаки включают в модель ключи.
Кстати, как ты предполагаешь делать выборку по ключу, если у тебя их нет?
Здравствуйте, drol, Вы писали:
D>Здравствуйте, syomin, Вы писали:
S>>Зависит от условий задачи: дата рождения, место жительства, серия + номер паспорта и т.д. и т.п.
D>Ну вот видите — указателей/ссылок, даже в элементарном сферовакуумном примере, недостаточно для эффективного обеспечения identity объектов.
Надо различать две задачи: идентификацию самих объектов предметной области, и идентификацию экземпляров классов в ООП. Идентификация объектов предметной области — широкая и местами сложная тема, в которой надо плясать в основном от требований к приложению. Идентификация экземпляров — вещь очень простая: у каждого объекта в памяти есть адрес, в дотнете можно сравнивать объекты на ссылочное равенство (ReferenceEquals). Суррогатные ключи в базе данных — это аналог адреса объекта для базы — нужен для удобного обращения к определенной строке таблицы. Строго говоря, primary key необходим ОРМ-у внутри себя для обеспечения identity mapping, а также для сохранения/удаления объектов в/из базы. То свойство/поле с первичным ключом, которое содержится в объекте — это не более чем копия настоящего значения primary key, и для ОРМ его наличие не играет особой роли. Если бы это было не так, ОРМ не смог бы обеспечить правильность работы при изменении пользователем первичного ключа в объекте. То есть наличие в объекте свойства Customer.CustomerID — это опция для удобства и для обеспечения возможности обращаться к primary key объекта из LINQ2Entity.
S>>Поймите простую вещь: если у нас первичный ключ является суррогатным, то в большинстве случаев никакого смысла показывать его пользователю нет,
D>Ничего подобного. Пользователь может его в виде компоненты http-ссылки наблюдать, например. А уж собственно потрохам приложения PK так и вообще на каждом шагу необходим...
Ну это правильно, но вынужденно, т.к. для URL необходим текстовый аналог уникальной ссылки на объект, и использовать для этого данные предметной области неудобно.
G>Кстати, как ты предполагаешь делать выборку по ключу, если у тебя их нет?
Чтобы сделать выборку по ключу, нужно этот ключ откуда-то взять. Варианты:
ключ берется из конфигурационного файла, приходит по сети, его вводит пользователь т.д. и т.п. Я выше неоднократно писал, что такого в рассматриваемой системе нет.
ключ берется из другой сущности, которая уже есть в БД. Здесь всё решается navigation properties, которые генерирует EF.
Другими словами, мне не нужно делать поиск по ключу в явном виде. Вообще. В неявном виде (т.е. в SQL запросе) ключ фигурирует, но эту работу ТЕОРЕТИЧЕСКИ мог бы взять на себя EF.
sto>Надо различать две задачи: идентификацию самих объектов предметной области, и идентификацию экземпляров классов в ООП. Идентификация объектов предметной области — широкая и местами сложная тема, в которой надо плясать в основном от требований к приложению. Идентификация экземпляров — вещь очень простая: у каждого объекта в памяти есть адрес, в дотнете можно сравнивать объекты на ссылочное равенство (ReferenceEquals). Суррогатные ключи в базе данных — это аналог адреса объекта для базы — нужен для удобного обращения к определенной строке таблицы. Строго говоря, primary key необходим ОРМ-у внутри себя для обеспечения identity mapping, а также для сохранения/удаления объектов в/из базы. То свойство/поле с первичным ключом, которое содержится в объекте — это не более чем копия настоящего значения primary key, и для ОРМ его наличие не играет особой роли. Если бы это было не так, ОРМ не смог бы обеспечить правильность работы при изменении пользователем первичного ключа в объекте. То есть наличие в объекте свойства Customer.CustomerID — это опция для удобства и для обеспечения возможности обращаться к primary key объекта из LINQ2Entity.
Спасибо за конструктивный ответ. Не подскажете, как можно сделать следующее:
Убрать свойство CustomerId из класса Product.
Убрать свойство Id у Product и Customer.
Здравствуйте, syomin, Вы писали:
G>>Кстати, как ты предполагаешь делать выборку по ключу, если у тебя их нет?
S>Чтобы сделать выборку по ключу, нужно этот ключ откуда-то взять. Варианты: S>
S> ключ берется из конфигурационного файла, приходит по сети, его вводит пользователь т.д. и т.п. Я выше неоднократно писал, что такого в рассматриваемой системе нет. S> ключ берется из другой сущности, которая уже есть в БД. Здесь всё решается navigation properties, которые генерирует EF. S>
S>Другими словами, мне не нужно делать поиск по ключу в явном виде. Вообще. В неявном виде (т.е. в SQL запросе) ключ фигурирует, но эту работу ТЕОРЕТИЧЕСКИ мог бы взять на себя EF.
Тогда тебе не нужна БД и ORM — сериализуй граф в файл и восстанавливай оттуда при запуске приложения. Иначе у тебя lazy load быстренько сам вытянет всю базу, а это все равно дольше выйдет.
G>Тогда тебе не нужна БД и ORM — сериализуй граф в файл и восстанавливай оттуда при запуске приложения. Иначе у тебя lazy load быстренько сам вытянет всю базу, а это все равно дольше выйдет.
Возможный вариант, но хотелось бы использовать единое "хранилище" объектов для нескольких экземпляров приложения. Клиент-сервер, другими словами.
Здравствуйте, syomin, Вы писали:
G>>Тогда тебе не нужна БД и ORM — сериализуй граф в файл и восстанавливай оттуда при запуске приложения. Иначе у тебя lazy load быстренько сам вытянет всю базу, а это все равно дольше выйдет.
S>Возможный вариант, но хотелось бы использовать единое "хранилище" объектов для нескольких экземпляров приложения. Клиент-сервер, другими словами.
Ну тогда тебе остается только свой ORM писать, покажи потом что получилось.
Здравствуйте, syomin, Вы писали:
G>>Ну тогда тебе остается только свой ORM писать, покажи потом что получилось. S>Проще победить чувство прекрасного...
Тебе все равно придется это делать, твой подход к работе с данными положит приложение даже на небольших объемах.
S> Убрать свойство CustomerId из класса Product. S> Убрать свойство Id у Product и Customer. S>
Если использовать NHibernate, то CustomerId исчезнет. От Id избавляться не следует. Хотя бы потому, что в списке пользователю показывается облегчённый объект, а по клику открывается карточка полного объекта. По ссылкам объекты разные, Id — одинаковые.
Здравствуйте, syomin, Вы писали:
S>Добрый день!
S>Только начинаю осваивать Entity Framework, поэтому вопрос в общем-то дилетантский...
S>Построил я модель предметной области по существующей базе данных с использование мастера из состава Visual Studio. В базе данных есть две таблицы: Customers и Products, для каждой из них определен первичный ключ (поле Id типа Guid). В таблице Products также имеется поле CustomerId и соответствующий внешний ключ, который связывает обе таблицы.
Я понимаю чего вы хотите добиться и для себя я выбрал BLToolkit вместо EF отчасти из аналогичных соображений.
В EF кое-что могло бы быть упрощено если бы EntityObject уже содержал некий общий Id который все равно нужен в каждом дочернем объекте.
Но для второго ID (CustomerId) проблема проистекает из реляционной модели данных вообще. Эта модель нуждается в ID, чтобы описать связи между объектами.
Иначе загрузка одного объекта потянет за собой всю базу данных, что совершенно ни к чему.
Здравствуйте, henson, Вы писали:
H>Здравствуйте, syomin, Вы писали:
S>>Добрый день!
S>>Только начинаю осваивать Entity Framework, поэтому вопрос в общем-то дилетантский...
S>>Построил я модель предметной области по существующей базе данных с использование мастера из состава Visual Studio. В базе данных есть две таблицы: Customers и Products, для каждой из них определен первичный ключ (поле Id типа Guid). В таблице Products также имеется поле CustomerId и соответствующий внешний ключ, который связывает обе таблицы.
H>Я понимаю чего вы хотите добиться и для себя я выбрал BLToolkit вместо EF отчасти из аналогичных соображений.
булкит — по большей части маппер, не умеет он identity map, поэтому ключики должны быть явными.
H>В EF кое-что могло бы быть упрощено если бы EntityObject уже содержал некий общий Id который все равно нужен в каждом дочернем объекте.
EntityKey?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, henson, Вы писали:
H>>Здравствуйте, syomin, Вы писали:
S>>>Добрый день!
S>>>Только начинаю осваивать Entity Framework, поэтому вопрос в общем-то дилетантский...
S>>>Построил я модель предметной области по существующей базе данных с использование мастера из состава Visual Studio. В базе данных есть две таблицы: Customers и Products, для каждой из них определен первичный ключ (поле Id типа Guid). В таблице Products также имеется поле CustomerId и соответствующий внешний ключ, который связывает обе таблицы.
H>>Я понимаю чего вы хотите добиться и для себя я выбрал BLToolkit вместо EF отчасти из аналогичных соображений. G> G>булкит — по большей части маппер, не умеет он identity map, поэтому ключики должны быть явными.
Соображение было такое, что если EF этого не делает, то лучше использовать BLToolkit, который все остальное намного легче и быстрей, даже если автоматического identity mapping там тоже нет
H>>В EF кое-что могло бы быть упрощено если бы EntityObject уже содержал некий общий Id который все равно нужен в каждом дочернем объекте. G>EntityKey?
EntityKey все-таки не поле в базе данных, а объект хранящий ссылку на ключевое поле, т.е. какой-то дополнительный Id ВСЕГДА нужен
Здравствуйте, henson, Вы писали:
H>>>В EF кое-что могло бы быть упрощено если бы EntityObject уже содержал некий общий Id который все равно нужен в каждом дочернем объекте. G>>EntityKey?
H>EntityKey все-таки не поле в базе данных, а объект хранящий ссылку на ключевое поле, т.е. какой-то дополнительный Id ВСЕГДА нужен
Неверно. http://msdn.microsoft.com/ru-ru/library/system.data.entitykey(VS.90).aspx
