Комментарии 13
catch
{
// ignored
Oo
внешние ключи в EF Core генерируют теневые свойства, используя шаблон [Entity]Id, в отличие от EF6, который использует шаблон [Entity]_Id. Поэтому вначале добавьте внешние ключи в качестве обычного свойства к сущности
Вообще-то, подобные проблемы решаются соглашениями (Conventions)
По сути это является одной из особенностей правил соглашения. Соглашение для внешнего ключа заключается в том, что имя должно следовать одному из следующих шаблонов:
[navigation property name][principal primary key property name]Id
[principal class name][primary key property name]Id
[principal primary key property name]Id
Но если вы решите не включать явное свойство внешнего ключа, EF Core создаст теневое свойство, используя идентификатор [principal primary key property name]Id. Нам было важно, чтобы при переходе ядра платформы на .net core, базы данных пользователей не требовали каких либо изменений.
[navigation property name][principal primary key property name]Id
[principal class name][primary key property name]Id
[principal primary key property name]Id
Но если вы решите не включать явное свойство внешнего ключа, EF Core создаст теневое свойство, используя идентификатор [principal primary key property name]Id. Нам было важно, чтобы при переходе ядра платформы на .net core, базы данных пользователей не требовали каких либо изменений.
объёмный туториал
Какая была основная причина переноса проекта?
.Net Core 3.0 и 3.1 теперь поддерживают полноценный EF 6, необязательно мучаться с миграцией.
Если чесно, я думаю они правильно поступили. EF 6 настолько уныло строит SQL запросы, что слеза наворачивается и одна надежда на мозг SQL оптимизатора.
Но, также замечу, что подход с Lazy Loading, на том же проекте привнес значительные тормоза у реальных пользователей системы с большими обьемами данных.
Сам поучавствовал в этом сраче 2015 года. Яркий пример как подход к базе данных как к тупому хранилищу объектов заканчиватся плачевно.
Но, также замечу, что подход с Lazy Loading, на том же проекте привнес значительные тормоза у реальных пользователей системы с большими обьемами данных.
Сам поучавствовал в этом сраче 2015 года. Яркий пример как подход к базе данных как к тупому хранилищу объектов заканчиватся плачевно.
Шаг 3. В .NET Core использован новый формат csproj файла
Стоит отметить принципиальное отличие между использованием packages.config (PC) и PackageReference (PR): при использовании PC, там указываются все пакеты, которые нужны проекту, если используется PR, то достаточно указать зависимости первого уровня, все остальное подтянется автомагически.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как проапгрейдить существующий проект с ASP.NET MVC на ASP.NET Core. Практическое руководство