Entity Framework 5 Именование перечисления

Я использую EF 5 с миграциями и кодом в первую очередь. Все это работает довольно хорошо, но есть некоторые проблемы/вопросы, которые я хотел бы решить.

Начнем с простого примера. Допустим, у меня есть таблица пользователей и таблица типов пользователей. Таблица типов пользователей — это таблица enum/lookup в моем приложении. Таким образом, пользовательская таблица имеет столбец UserTypeId и ссылку на внешний ключ и т. д. для UserType. В моем poco у меня есть свойство UserType, которое имеет тип enum.

Чтобы добавить начальные значения в таблицу UserType (или добавить/изменить значения позже) и создать таблицу в начальном средстве миграции и т. д. Мне нужна таблица poco UserType для представления фактической таблицы в базе данных и для использования в файлах карты. Я сопоставил свойство UserType в poco User с UserTypeId в poco UserType. Итак, теперь у меня есть poco для кода сначала/миграции/сопоставления контекста и т. д., и у меня есть перечисление. Не может быть одинакового имени для обоих, поэтому у меня есть poco с именем UserType и что-то еще для перечисления или poco для UserType должно быть UserTypeTable или что-то в этом роде?

Однако, что еще более важно, я упускаю какой-то ключевой элемент в том, как сначала работает код? Я попробовал приведенный выше пример, запустил Add-Migration, и он не добавляет таблицу поиска для перечисления.


enums c# entity-framework-5 .net-4.5
person Tyrel Van Niekerk    schedule 13.04.2012    source источник
comment
Похоже, вы хотите что-то похожее на stackoverflow.com/q/11167665/10245   -  person Tim Abell    schedule 01.06.2016

Ответы (2)


arrow_upward
2
arrow_downward

Если я правильно понял ваши вопросы и то, что вас смущает,

Enums support has nothing to do with lookup tables on the Db side.

Перечисления просто позволяют вам иметь свойства в ваших классах, которые являются Enum-s и которые в основном переводятся в 'int'-s - так что там больше ничего нет.

Для получения дополнительной информации вы можете посмотреть это видео с сайта Джули Лерман о поддержке Enum

надеюсь это поможет

person NSGaga-mostly-inactive    schedule 13.04.2012
comment
Я думаю, он говорит, что у него есть поле UserTypeId, которое он хочет сопоставить как с перечислением (скажем, UserTypeEnum), так и с внешним ключом в классе для своей таблицы поиска (скажем, UserTypeClass). - person Brian Cauthon; 13.04.2012
comment
Да, Брайан, это правильно. Я пытаюсь выяснить правильную комбинацию, чтобы сначала код был чистым (с использованием перечисления), но все же создавал/подключался к таблице поиска в БД. Я знаю, что поддержка enum есть только на стороне кода, но на практике вам все равно нужна таблица поиска, чтобы гарантировать допустимые значения в БД. В настоящее время здесь на работе у нас есть генератор, который генерирует перечисление из таблицы поиска (включая атрибуты EnumMember с описанием). Если вы сначала используете БД с моделью, вы можете установить столбец типа enum, и он создаст для вас перечисление из БД. - person Tyrel Van Niekerk; 16.04.2012
comment
@TyrelVanNiekerk Я понимаю - я думаю, вы можете заставить оба работать вместе (это похоже на пользовательское сопоставление FK-s и т. Д.). Но не могли бы вы просто указать, чего именно вы хотите достичь (например, иметь enum + ID, который является FK для таблицы поиска и класса, но тогда вы должны иметь, я думаю, также класс поиска, кроме перечисления - или вы просто нужна «невидимая» таблица поиска и т. д.), и я отредактирую вопрос с конкретным решением. - person NSGaga-mostly-inactive; 16.04.2012
comment
@NSGaga В итоге я изменил сгенерированный код миграции. По умолчанию он хочет создать столбец UserTypeLookup_UserTypeId и FK вместо использования UserTypeId. Мне пришлось создать как перечисление, так и класс поиска, чтобы удовлетворить код first/mapping/migrator. - person Tyrel Van Niekerk; 16.04.2012
comment
Да, определенно звучит так, будто вам нужен мой (бесстыдный плагин) пакет nuget ef-enum-to-lookup - stackoverflow.com/a/26528355/ 10245 / nuget.org/packages/ef-enum-to- поиск - person Tim Abell; 01.06.2016

arrow_upward
0
arrow_downward

По моему опыту, перечисление важнее для вашего кода, чем класс поиска, поэтому дайте ему правильное имя. Я бы также изолировал класс поиска без какой-либо связи с пользователем в моей модели. Если это действительно только для поиска, то вам не нужно, чтобы он зависал от вашего пользователя. Ваше перечисление с DescriptionAttribute может выполнить поиск в вашем коде.

UserTypeLookup может быть хорошим именем, так как оно похоже на то, для чего вы будете его использовать. Затем вы можете использовать этот класс для обслуживания таблицы.

Предполагая, что вы сначала не сопоставляете связь между UserTypeLookup и User в коде ef, единственное, что вам нужно создать в БД вручную, — это отношение внешнего ключа между столбцом UserType в вашей таблице User и PK из таблицы UserTypeLookup. UserTypeLookup по-прежнему может быть сущностью, и EF все равно должен генерировать для нее таблицу БД, даже если вы не устанавливаете для нее никаких отношений.

person Brian Cauthon    schedule 13.04.2012
comment
Согласованный. На самом деле я назвал свой класс поиска, как вы сказали. Проблема, которую я пытаюсь решить сейчас, заключается в том, что, поскольку я настроил poco для использования перечисления и кода карты для использования поиска, миграционная программа рассматривает это как изменение и пытается изменить базу данных, добавив столбец с именем UserTypeLookup. Я ожидаю, что поиск в БД будет работать. Возможно, мне придется прибегнуть к ручному созданию таблицы и т. Д. В коде переносчика. - person Tyrel Van Niekerk; 16.04.2012