Можно ли использовать две ORM в проекте?

Question

[Дмитрий]

Ребятки подскажите) Как все мы знаем, что Entity Framework не балует нас производительность, в связи с этим вопрос такой, можно ли использовать две ORM в проекте, dapper - для выборки данных, а EF - для изменения данных?

Answer 1

[Дмитрий Ковальский]

Беспокоитесь за производительность? пишите руками через SqlConnection/Command. Напишите Data Access Layer. Чем городить огород - займитесь разработкой простеньких оберток.

Comments

[Дмитрий]

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

Answer 2

[Арам Арамян]

1. Можно использовать.
2. Для большинства проектов EF будет более чем достаточно. Потеря производительности - преувеличена. Встроенные механизмы кэширования и оптимизации запросов работают.
3. В "узких" местах проекта всегда можно использовать "легкую" ORM или прямой вызов SQL-запроса/хранимой процедуры. Но только тогда, когда в этом есть реальная необходимость.
4. EF экономит время разработчика не только потому, что это ORM, но и потому, что это ORM от Microsoft и Visual Studio отлично с ней дружит.

P.S. Просто поверьте человеку с 12-летним опытом работы с .NET, который потратил много времени на то, чтобы понять, что EF - достаточно. Я читал кучу статей и бенчмарков. Я тестил сам. Плюсы EF с лихвой покрывают небольшую потерю скорости.

Comments

[Алексей Немиро]

2. Не согласен :-)

Я видел, как мощный сервер несколько мину загружает 500 записей из базы; это даже не смешно, за такое компьютер нужно отбирать, пожизненно :-) До этого я наивно полагал, что хуже, чем некоторые встроенные решения WebForms быть уже ничего не может.

Видел, как люди подключали множество компонентов для улучшения производительность EF, но это, разумеется, ни к чему не приводило (сам факт существования таких компонентов говорит о многом).

Как-то оптимизировал один продолжительный процесс. Исходная версия работы с БД была реализована на EF. Полный цикл операции занимал более 48 часов. Ради эксперимента попробовал оставить EF. Сократил время до 4 часов. Но это было очень много, для обработки каких-то 200k строк данных. Плюнул и сделал без EF, сократив время выполнения задачи до 5 минут. А ведь кто-то изначально все это разрабатывал и тратил уйму времени на тестирование.

EF нельзя давать в руки новичкам. Многие не понимают, что вообще там происходит и творят жуткие вещи, так что бедным заказчикам приходится парки серверов арендовать, в то время как можно ограничиться дешевым виртуальным хостингом :-)

4. Сомнительная экономия, уж больно часто приходится переделывать такие "разработки".
Для обучения, для небольших простых проектов пойдет. Но для чего-то серьезного EF будет не лучше стандартных классов работы с БД, может даже хуже (из-за отсутствия/плохой прозрачности).

[Арам Арамян]

С такой точкой зрения, ASP.NET нельзя давать в руки новичков. Потому что без EF можно нагородить гораздо больше ошибок, в том числе с безопасностью и целостностью БД.
Экономия вполне реальная. В умелых руках EF становится очень удобным инструментом, позволяющим избежать многих рутинных задач.