Отличие ado net от entity framework

Обновлено: 06.07.2024

Предоставление жизненного цикла моделям

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

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

Entity Framework дает жизнь модели, позволяя разработчикам запрашивать сущности и связи в модели предметной области (называемой концептуальной моделью в Entity Framework), в то же время полагаться на Entity Framework преобразования этих операций в команды, относящиеся к источнику данных. Это позволяет отказаться от применения в приложениях жестко заданных зависимостей от конкретного источника данных.

При работе в режиме Code First концептуальная модель сопоставлена с режимом хранения в коде. Entity Framework может вычислять концептуальную модель на основе типов объектов и дополнительных конфигураций, которые вы определяете. Метаданные сопоставления формируются во время выполнения на основе сочетания определений типов домена и дополнительной информации о конфигурации, которая указана в коде. Entity Framework создает базу данных по мере необходимости на основе метаданных. Дополнительные сведения см. в разделе Создание модели.

При работе со средствами работы с моделью EDM концептуальная модель, модель хранения и сопоставление между ними выражены в схемах на основе XML и определены в файлах с именами с соответствующими расширениями.

Язык CSDL определяет концептуальную модель. Язык CSDL — это реализация EDMEntity Framework. Расширение файла - CSDL.

Язык SSDL определяет модель хранения данных, которая также называется логической моделью. Расширение файла - SSDL.

Язык MSL определяет сопоставление модели хранения и концептуальной модели. Расширение файла - MSL.

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

Entity Framework использует эти файлы модели и сопоставления для создания, чтения, обновления и удаления операций с сущностями и связями в концептуальной модели в эквивалентных операциях в источнике данных. Entity Framework даже поддерживает сопоставление сущностей в концептуальной модели с хранимыми процедурами в источнике данных. Дополнительные сведения см. в статье спецификации на языке CSDL, SSDL и MSL.

Сопоставьте объекты с данными

При использовании объектно-ориентированного программирования для взаимодействия с системами хранения данных возникают сложности. Безусловно, организация классов часто напоминает организацию таблиц реляционной базы данных, но такое соответствие неидеально. Несколько нормализованных таблиц часто соответствуют единственному классу, а связи между классами представлены не так, как связи между таблицами. Например, для представления клиенту заказа на продажу в классе Order может использоваться свойство, содержащее ссылку на экземпляр класса Customer , но строка таблицы Order базы данных содержит столбец внешнего ключа (или набор столбцов) со значением, которое соответствует первичному ключу в таблице Customer . Класс Customer может включать свойство с именем Orders , содержащее коллекцию экземпляров класса Order , но таблица Customer базы данных не содержит сравнимого столбца. Entity Framework предоставляет разработчикам гибкие возможности для представления связей таким образом или для более тесной связи между моделями, как они представлены в базе данных.

В существующих решениях была предпринята попытка устранить этот разрыв, часто называемый «несоответствием типов данных» (impedance mismatch), путем сопоставления с реляционными таблицами и столбцами только объектно-ориентированных классов и свойств. Вместо использования этого традиционного подхода Entity Framework сопоставляет реляционные таблицы, столбцы и ограничения внешнего ключа в логических моделях с сущностями и связями в концептуальных моделях. Это позволяет достичь большей гибкости при определении объектов и оптимизации логической модели. Средства EDM создают расширяемые классы данных на основе концептуальной модели. Эти классы являются разделяемыми классами, которые могут быть расширены с помощью дополнительных членов, добавленных разработчиком. По умолчанию классы, сформированные для определенной концептуальной модели, являются производными от базовых классов, предоставляющих службы для материализации сущностей в виде объектов, а также для отслеживания и сохранения изменений. Разработчики могут использовать эти три класса для работы с сущностями и связями как с объектами, относящимися к ассоциациям. Разработчики смогут также настраивать классы, сформированные для концептуальной модели. Дополнительные сведения см. в разделе Работа с объектами.

Доступ и изменение данных сущности

Платформа Entity Framework — это не просто еще одно средство объектно-реляционного сопоставления. Ее цель — предоставить приложениям возможность чтения и изменения данных, представленных в виде сущностей и связей в концептуальной модели. Entity Framework использует сведения в файлах модели и сопоставления для преобразования запросов объектов в типы сущностей, представленные в концептуальной модели, в запросы, относящиеся к источникам данных. Результаты запроса собиваются на объекты, которыми управляет Entity Framework. Entity Framework предоставляет следующие способы запроса концептуальной модели и возврата объектов.

LINQ to Entities. Обеспечивает поддержку запросов LINQ для выполнения запросов к типам сущности, которые определены в концептуальной модели. дополнительные сведения см. в разделе LINQ to Entities.

Entity SQL. независимый от хранилища диалект SQL, который работает непосредственно с сущностями в концептуальной модели и поддерживает EDM концепции. Entity SQL используется как с запросами объектов, так и с запросами, которые выполняются с помощью поставщика EntityClient. дополнительные сведения см. в разделе Entity SQL обзор.

На следующей схеме показана архитектура, применяемая в платформе Entity Framework для доступа к данным.

Средства EDM могут создать класс, производный от System.Data.Objects.ObjectContext или System.Data.Entity.DbContext , представляющий контейнер сущностей в концептуальной модели. Контекст объекта предоставляет средства для отслеживания изменений и управления идентификаторами, параллелизмом и связями. Этот класс представляет также доступ к методу SaveChanges , который записывает результаты вставки, обновления и удаления данных в источник данных. Подобно запросам, эти изменения производятся либо командами, автоматически сформированными системой, либо хранимыми процедурами, указанными разработчиком.

Поставщики данных

Entity Framework включает обновленный поставщик данных SqlClient, который поддерживает канонические деревья команд. Дополнительные сведения см. в разделе SqlClient для Entity Framework.

Средства модели EDM

вместе со средой выполнения Entity Framework Visual Studio включает средства сопоставления и моделирования. Дополнительные сведения см. в разделе моделирование и сопоставление.

Дополнительные сведения

Дополнительные сведения о Entity Framework см. в следующих статьях:

Начало работы — содержит сведения о том, как быстро начать работу с помощью краткого руководства, в котором показано, как создать простое приложение Entity Framework.

Entity Framework терминология определяет множество терминов, которые появились EDM и Entity Framework и используются в документации Entity Framework.

Entity Framework ресурсы — ссылки на основные разделы и ссылки на внешние разделы и ресурсы для создания Entity Framework приложений.

ИМХО зависит от знаний и построения процесса разработки, плюс от источника данных. Мне лично значительно удобнее ado( на любой сложности запросов и кол-ве данных) , но для большинства "опп" разработчиков это тёмный лес. Плюс лично мне не нравиться подход code first.

Смотря кто как учился работать с базой из кода. Мне сначала пришлось ADO изучать и юзать, только потом ORM подъехала.

Соглашусь и с OnYourLips и с @nApoBo3
OnYourLips отметил, что ADO более гибкая, в том плане, что можно написать запрос любой сложности и при этом ни чего кроме базы затрагиваться не будет.
nApoBo3 же отметил тот факт, что это выбор частично зависит от "построения процесса разработки"
Резюмируя, могу дополнить только одно - можно работать и с тем и с другим, но можно всю логику перенести из кода в базы, если быть точнее в функции и процедуры. Их удобно вызывать как из ADO, так и из EF, но в добавок еще и иметь объектное представление базы (entities)

". можно всю логику перенести из кода в базы, если быть точнее в функции и процедуры. " - поддержу, с двумя дополнениями: 1)необходимо тщательно продумать структуру БД, 2) тщательно документировать код процедур и функций, желательно с перекрестными ссылками. Иначе получается тяжело поддерживаемый или вообще неподдерживаемый код.

Андрей Скоржинский: +
на самом деле, в любом случае, все и упирается в качество проектирования всего решения

в зависимости от задач. EF конечно более мощный, гибкий, но и тяжеловесный. на хабре выкладывали тесты его не высокой производительности. Я все новые проекты на dapper делаю, и скорость айс и все просто.

Подскажи, пожалуйста, может сталкивался. EF был очень медленный, попробовали Dapper, все круто, только иногда случается ошибка "Unable to connect to any of the specified MySQL hosts" и запись не проходит. С чем может быть связано? Происходит не часто, в основном нормально все пишет. Это может быть связано с отсутствием пула подключений?

Соглашусь и с OnYourLips и с @nApoBo3

OnYourLips отметил, что ADO более гибкая, в том плане, что можно написать запрос любой сложности и при этом ни чего кроме базы затрагиваться не будет.

29 окт. 2021, в 03:34

29 окт. 2021, в 00:33

145000 руб./за проект

28 окт. 2021, в 23:35

35000 руб./за проект

приложение планируется быть довольно большим и служите большое количество клиентов вытягивая и уточняя высокий freq. изменить данные.

мой план для этого проекта, чтобы использовать VS2010 и новая структура EF4.

Это буду рад услышать другие параметры программистов о разработке с Entity Framework

плюсы и минусы от предыдущих опыт?

Как вы думаете, EF4 готов к производство?

однако: вам нужно учитывать, что EF пытается решить; это двухслойный подход, один слой сопоставляется с вашей физической схемой хранения в вашей базе данных (и поддерживает несколько бэкэндов), а второй слой-ваша концептуальная модель, с которой вы программируете. И конечно, существует необходимость в отображении между этими двумя слоями.

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

но это стоит-эти дополнительные слои влияют на производительность, сложность, ремонтопригодность. Если вам нужны эти функции, вы будете счастлив заплатить эту цену, без вопросов. Но тебе это нужно??

поэтому моя рекомендация будет такая:

если вам нужен только SQL Server в качестве бэкэнда
если у вас есть довольно простое и простое сопоставление одной таблицы базы данных с одним объектом сущности в вашем модель

теперь я использую оба, потому что некоторые вещи linq to sql(и любой ORM, как EF) не могут сделать. Мне пришлось сделать несколько массовых вставок, и я сделал это сначала с linq to sql и сделать 500 записей, это заняло 6 минут(2 минуты для правил проверки rest вставлялся в БД).

Я изменил его на SQL bulk copy, и теперь он до 2min и 4 секунд(4 секунды, чтобы сделать все вставки)

скажем, моя таблица была длиной 10 столбцов и называлась таблицей A. Я использовал linq to sql и сделал таблицу объектом класса( new TableA()) и заполнил ее данными. Затем я передал бы этот объект методу, который создал datarow.

таким образом, linq to sql сэкономил мне некоторое время, потому что я, вероятно, сделали класс, так как я бы не хотел передавать 10 параметров в метод, который делает строку данных. Я также чувствую, что это дает немного типичности, поскольку вы должны передать правильный объект, чтобы использовать этот метод, поэтому меньше шансов передать неправильные данные.

наконец, вы все еще можете использовать linq to sql для вызова хранимых процедур, и это похоже на одну строку кода.

EF 4 теперь больше похож на LINQ to SQL, в хорошем смысле; он имеет ключи FK прямо в объекте, имеет методы add прямо в наборах объектов и множество других приятных функций. Дизайнер значительно улучшен, и основным плюсом является то, что он работает с SQL и Oracle, и, возможно, некоторые другие (если поставщик поддерживает его) вместо LINQ to SQL только с SQL Server.

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 28 марта 2021; проверки требуют 9 правок.

Версия 6.0 была выпущена 17 октября 2013 года[3] и сейчас это проект с открытым исходным кодом под лицензией Apache License v2. В версии 6.0 был сделан ряд улучшений в поддержке метода работы Code First.

Entity SQL представляет собой язык, подобный языку SQL, который позволяет выполнять запросы к концептуальным моделям в Entity Framework[4].

Это альтернативный интерфейс LINQ API, используемый для обращения к базе данных. Он отделяет сущностную объектную модель данных от физической базы данных, вводя логическое отображение между ними. Так, например, схемы реляционных баз данных не всегда подходят для построения объектно-ориентированных приложений и в результате мы имеем объектную модель приложения, существенно отличающуюся от логической модели данных, в этом случае используется LINQ to Entities, который использует модель EDM (Entity Data Model). То есть, если вам нужно ослабить связь между вашей сущностной объектной моделью данных и физической моделью данных, например, если ваши сущностные объекты конструируются из нескольких таблиц или вам нужна большая гибкость в моделировании ваших сущностных объектов используйте LINQ to Entities.

Руководство по Entity Framework
Что такое Entity Framework

Entity Framework: как быстрее написать код для работы с базой данных

Код взаимодействия с базой данных может быть очень громоздким, однако его можно сократить, воспользовавшись Entity Framework.

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Для начала создайте проект Console Application в Visual Studio. Затем откройте менеджер пакетов NuGet:

И скачайте пакет с этим фреймворком:

Когда он установится, нужно подключиться к СУБД. Это делается с помощью файла конфигурации. Так как рассматривается консольное приложение, то надо открыть файл App.config:

В него вносится информация о СУБД. Для этого после элемента <configSections> добавляем следующее:

Отсюда фреймворк будет брать connectionString. В этом примере приложение будет подключаться к SQLEXPRESS, но можно использовать и localdb. При этом достаточно указать любое название самой базы данных: если её не существует, EF создаст её сам. То же самое касается и всех таблиц.

Закончив с файлом конфигурации, можно приступать к работе с кодом.

В этой статье будет рассмотрен подход Code first, в котором сначала пишется код, а потом на его основе работает база данных.

public class Player < public int Id < get; set; >public string Nickname < get; set; >public int Rank < get; set; >>

Несмотря на то что класс называется PlayerContext, его можно использовать для работы с любыми другими сущностями. Для этого нужно только добавить ещё несколько коллекций DbSet.

Теперь всё готово и можно приступить к работе с базой данных. Начать стоит с объявления первых объектов и их добавления в БД.

Запустив программу с таким кодом, можно увидеть, что всё успешно сохранилось:

Теперь пора проверить, есть ли что-нибудь в базе данных в таблице Players. Для этого можно просто вывести данные из объектов в свойстве Players.

Вот что должно получиться:

Тут видно, что Entity Framework автоматически указал свойство Id как первичный ключ, поэтому значения заполняются автоматически.

Linq добавляет в язык программирования синтаксис, напоминающий используемый в SQL. Например, для выборки можно использовать метод Where (), который позволяет получить все строки из таблицы, если они соответствуют утверждению.

var players = db.Players.Where(p => p.Rank >= 10);

Вот как выглядит редактирование строк в Entity Framework:

Вот что будет выведено в результате работы такого кода:

Никнейм игрока был успешно изменён. Теперь можно попробовать удалить эту сущность из базы данных.

Тут уже можно увидеть, что проверяется, не равен ли объект null, потому что иначе будет вызвано исключение NullReferenceException.

Вот каким будет вывод:

Entity Framework позволяет значительно сократить код работы с базами данных. При этом он предоставляет большие возможности. Например, можно использовать:

foreign keys;
связи one-to-one, one-to-many и many-to-many;
параметризацию запросов;
хранимые процедуры.

мой план для этого проекта, чтобы использовать VS2010 и новая структура EF4.

Это буду рад услышать другие параметры программистов о разработке с Entity Framework

плюсы и минусы от предыдущих опыт?

Как вы думаете, EF4 готов к производство?

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

конечно, вы можете вернуться к прямой ADO.NET -но вы действительно хотите возиться с DataTables, DataRows и untyped Row["RowName"] снова создает?? Неужели.

поэтому моя рекомендация будет такая:

если вам нужен только SQL Server в качестве бэкэнда
если у вас есть довольно простое и простое сопоставление одной таблицы базы данных с одним объектом сущности в вашем модель

Я изменил его на SQL bulk copy, и теперь он до 2min и 4 секунд(4 секунды, чтобы сделать все вставки)

но, как сказал marc_s, я действительно не хотел возиться с DataTables, DataRows и нетипизированной строкой["RowName"].

наконец, вы все еще можете использовать linq to sql для вызова хранимых процедур, и это похоже на одну строку кода.

Читайте также: