Entity Framework: Как я могу включить одну таблицу на наследование класса с полем rowversion?

Question

Почему я не могу определить члена с тем же именем в подклассах? У меня есть одна таблица для каждого класса наследования с полем timeversion timestamp в каждой таблице. Похоже, что Entity Designer должен учитывать это и использовать ключевое слово new в свойстве, чтобы это произошло. Какой обходной путь? Как я могу указать одно и то же поле в цепочке наследования с разными значениями, если я не могу использовать new ? Это может быть верно для других баз данных, в которых есть rowguids, ModifiedBys, ModifiedDates и т. Д.

Редактировать . Я думаю, что логичный способ сделать это - просто переименовать ссылку на поле, то есть PersonRowversion в Student класс, который происходит от Person .

Мне не хватает фрагмента EF, который может автоматически отслеживать поля такого типа?

Answer 1

Потому что класс не может иметь двух членов с одинаковыми именами. & Quot; новый & Quot; не буду делать то, что вы хотите. & Quot; новый & Quot; скрывает унаследованный член; это не дает вам двух разных участников с одинаковым именем. Так что, если сгенерированный код использовал "новый" тогда вы никогда не сможете получить доступ к значению в " родительской таблице " из вашего кода C #. Для обеих таблиц базы данных хорошо иметь два столбца с одинаковыми именами, но вам нужно переименовать повторяющиеся имена столбцов в вашей концептуальной модели, когда две таблицы составляют один класс.

С точки зрения " измененной даты " и т. д., как правило, вам нужен только один. Если у вас есть супертип Animal и подтип Dog, Entity Framework рассматривает возможность обновления «порции животных». или «собачья порция»; типа для обновления всего экземпляра, как это делает C #.

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

Одним из ментальных барьеров, которые вы должны преодолеть при разработке хорошего объектного реляционного отображения, является склонность мыслить в первую очередь в объектно-ориентированных или реляционных терминах, в зависимости от того, что подходит вашей личности. Хорошее объектное реляционное отображение, тем не менее, включает в себя как хорошую объектную модель, так и хорошую реляционную модель. Например, допустим, у вас есть база данных с таблицей для сотрудников и связанными таблицами для сотрудников и клиентов. Один человек может иметь запись во всех трех таблицах. Теперь, с строго реляционной точки зрения, вы можете создать базу данных VIEW для сотрудников и другую для клиентов, которые содержат информацию из таблицы People. При использовании одного или другого ПРОСМОТРА вы можете временно думать об отдельном человеке как о "просто" Сотрудник или "просто" Клиент, даже если вы знаете, что они оба. Таким образом, у кого-то из этого мировоззрения может возникнуть соблазн сделать OO-отображение, где Employee и Customer являются (прямыми) подклассами Person. Но это не работает с имеющимися у нас данными; поскольку у одного лица есть записи как о сотруднике, так и о клиенте (и поскольку ни один экземпляр Person не может одновременно иметь конкретный подтип Employee и Customer), отношение OO между Person и Employee должно быть составным, а не наследованием, и аналогично для Person и Customer.