К тому моменту, когда вы завершите изучение этих двух глав, у вас будет финальная версия уровня доступа к данным для базы данных AutoLot. Прежде чем заняться непосредственно инфраструктурой EF Core, давайте обсудим инструменты объектно-реляционного отображения в целом.
На заметку! Двух глав далеко не достаточно, чтобы охватить все аспекты инфраструктуры Entity Framework Core, т.к. ей посвящены целые книги (по объему сравнимые с настоящей). Цель предлагаемых глав — предложить вам практические знания, которые позволят приступить к применению EF Core для разработки своей линейки бизнес-приложений.
Инфраструктура ADO.NET снабжает вас структурой, которая позволяет выбирать, вставлять, обновлять и удалять данные с помощью объектов подключений, команд и чтения данных. Тем не менее, такие аспекты ADO.NET вынуждают обходиться с извлеченными данными в манере, тесно связанной с физической схемой базы данных. В качестве примера вспомните, что при получении записей из базы данных вы открываете объект подключения, создаете и выполняете объект команды и затем используете объект чтения данных для прохода по записям с применением имен столбцов, зависящих от базы данных.
При работе с ADO.NET вы всегда обязаны помнить о физической структуре серверной базы данных. Вы должны знать схему каждой таблицы данных, создавать потенциально сложные запросы SQL для взаимодействия с таблицей (таблицами) данных, отслеживать изменения в извлеченных (или добавленных) данных и т.д. В итоге вы можете быть вынуждены записывать довольно многословный код С#, поскольку сам язык C# не позволяет работать непосредственно со схемой базы данных.
Хуже того, обычный способ создания физической базы данных прямо сосредоточен на конструкциях базы данных, таких как внешние ключи, представления, хранимые процедуры и нормализация данных, а не на объектно-ориентированном программировании.
Еще одним вопросом у разработчиков приложений, требующим решения, является отслеживание изменений. Получение данных из базы — один из этапов процесса, но любые изменения, добавления и/или удаления должны отслеживаться разработчиком, чтобы их можно было сохранить в хранилище данных.
Доступность инфраструктур create, read, update, delete — CRUD). Разработчик создает отображение между объектами .NET и реляционной базой данных, а инфраструктура ORM управляет подключениями, генерацией запросов, отслеживанием изменений и хранением данных. В итоге разработчик получает возможность целиком сосредоточиться на бизнес-потребностях приложения.
На заметку! Важно помнить, что инфраструктуры ORM не являются инструментами, которые с легкостью решат все проблемы.С каждым решением связаны компромиссы. Инфраструктуры ORM сокращают объем работы разработчикам, создающим уровни доступа к данным, но могут также привносить проблемы с производительностью и масштабированием в случае ненадлежащего применения. Используйте инфраструктуры ORM для операций CRUD и задействуйте мощь своей базы данных для операций, основанных на множествах.
Хотя разные инфраструктуры ORM имеют небольшие отличия в том, как они работают, или каким образом применяются, все они по существу представляют собой одни и те же фрагменты и части, преследующие ту же самую цель — облегчить выполнение операций доступ к данным. Сущности являются классами, которые отображаются на таблицы базы данных. Специализированный тип коллекции содержит одну или большее количество сущностей. Механизм отслеживания изменений следит за состоянием объектов и любыми связанными с ними изменениями, добавлениями и/или удалениями, а центральная конструкция управляет операциями как руководитель.
"За кулисами" EF Core использует инфраструктуру ADO.NET, которая уже была исследована в предыдущей главе. Подобно любому взаимодействию ADO.NET с хранилищем данных EF Core применяет для этого поставщик данных ADO.NET. Прежде чем поставщик данных ADO.NET можно будет использовать в EF Core, его потребуется обновить для полной интеграции с EF Core. Из-за такой добавленной функциональности доступных поставщиков данных EF Core может оказаться меньше, чем поставщиков данных ADO.NET.
