В версии EF Core 5.0 команда scaffold стала работать гораздо надежнее. Как видите, на выбор предлагается довольно много вариантов. Если выбран вариант с аннотациями данных (-d), тогда EF Core будет применять аннотации данных там, где это возможно, и заполнять отличия с использованием Fluent API. Если вариант с -d не выбран, то вся конфигурация (отличающаяся от соглашений) кодируется с помощью Fluent API. Вы можете указывать пространство имен, схему и местоположение для генерируемых файлов с сущностными классами и классом, производным от DbContext. Если вы не хотите создавать шаблон для целой базы данных, тогда можете выбрать определенные схемы и таблицы. Параметр --no-onconfiguring позволяет исключить метод OnConfiguring из шаблонного класса, а параметр --no-pluralize отключает средство перевода имен в множественное число. Упомянутое средство превращает имена сущностей в единственном числе (Car) в имена таблиц во множественном числе (Cars) при создании миграций и имена таблиц во множественном числе в имена сущностей в единственном числе при создании шаблона.

Резюме

В настоящей главе вы начали ознакомление с инфраструктурой Entity Framework Core. В ней были исследованы аспекты, лежащие в основе EF Core, выполнения запросов и отслеживания изменений. Вы узнали о придании формы своей модели, соглашениях EF Core, аннотациях данных и Fluent API, а также о том, как их применение влияет на проектное решение для базы данных. Наконец, вы научились пользоваться мощным интерфейсом командной строки EF Core и глобальными инструментами.

Наряду с тем, что в этой главе было предложено много теоретических сведений и мало кода, следующая глава содержит главным образом код и совсем немного теории. По завершении проработки материалов главы 23 в вашем распоряжении появится законченный уровень доступа к данным AutoLot.

Глава 23

Построение уровня доступа к данным с помощью Entity Framework Core

В предыдущей главе раскрывались детали и возможности инфраструктуры EFCore. Текущая глава сосредоточена на применении того, что вы узнали об инфраструктуре EF Core, для построения уровня доступа к данным AutoLot. В начале главы строятся шаблоны сущностей и производного от DbContext класса для базы данных из предыдущей главы. Затем используемый в проекте подход "сначала база данных" меняется на подход "сначала код", а сущности обновляются до своей финальной версии и применяются к базе данных с использованием миграций EF Core. Последним изменением, внесенным в базу данных, будет воссоздание хранимой процедуры GetPetName и создание нового представления базы данных (в комплекте с соответствующей моделью представления), что делается с помощью миграций.

Следующий шаг — формирование хранилищ, обеспечивающих изолированный доступ для создания, чтения, обновления и удаления (create, read, update, delete — CRUD) базы данных. Далее в целях тестирования к проекту будет добавлен код инициализации данных вместе с выборочными данными. Остаток главы посвящен испытаниям уровня доступа к данным AutoLot посредством автоматизированных интеграционных тестов.

"Сначала код" или "сначала база данных"

Прежде чем приступить к построению уровня доступа к данным, давайте обсудим два способа работы с EF Core и базой данных: "сначала код" или "сначала база данных". Оба они совершенно допустимы, а выбор применяемого подхода в значительной степени зависит от самой команды разработчиков.

Подход "сначала код" означает, что вы создаете и конфигурируете свои сущностные классы и производный от DbContext класс в коде и затем используете миграции для обновления базы данных. Подобным образом разрабатывается большинство новых проектов. Преимущество подхода "сначала код" заключается в том, что в ходе построения приложения сущности развиваются на основе имеющихся у него потребностей. Миграции поддерживают синхронизацию с базой данных, поэтому проектное решение базы данных эволюционирует вместе с приложением. Такой развивающийся процесс проектирования популярен в командах гибкой разработки, поскольку он обеспечивает создание нужных частей в надлежащее время.