Когда используют низкоуровневый ADO.net, а когда Entity Framework?

Question

[wol2for]

На собеседовании спросили "Когда используют низкоуровневый ADO.net (disconnec и connect), а когда Entity Framework?"
Люди с опытом работы с ADO.net и EF, подсобите в этом вопросе. И, еще вопрос, в процентом соотношение, какую технологию вы чаще применяете в работе ADO.net(disconnec) или ADO.net(connect) или EF?

Answer 1

[nApoBo3]

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

Comments

[Дмитрий Гавриленко]

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

Answer 2

[IlyaMS]

EF (особенно с CodeFirst) позволяет разрабатывать БД и логику работы с ней быстрее и на C# (практически не залезая в SQL). Кроме того, благодаря миграциям обеспечивается консистентное состояние структуры БД (Петя и Вася не смогут поменять что-то в базе, не получив конфликта в системе контроля версий при мердже). Из минусов - ограничения, которые EF накладывает на ваши возможности (ADO в этом плане более низкоуровневое => более мощное средство), а также неоптимальность и нечитабельность SQL-кода, который EF генерирует в ответ на ваш красивый и понятный код с использованием LINQ (достаточно залезть в то, что генерит EF на любой среднестатистический нетривиальный запрос с несколькими связанными сущностями - и ужаснуться).

Answer 3

[Дмитрий Гавриленко]

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

Comments

[Андрей Скоржинский]

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

[Дмитрий Гавриленко]

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

Answer 4

[Дмитрий Филандор]

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

Comments

[GantZ_Yaka]

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