Должен ли я использовать Dapper вместо Entity Framework?

Меня направили на этот пост Должен ли я использовать Entity Framework? @Тим Кори клиентом, у которого возникли проблемы с адаптацией некоторых примеров кода EF и OData для Dapper. Проблема в том, что Dapper и EF предназначены для решения разных задач. В то время как dapper упрощает и делает более безопасным написание и выполнение необработанных SQL-запросов, EF полностью абстрагирует SQL, но при этом предоставляет вам функции, очень похожие на Dapper, если они вам действительно нужны.

Я прямо изложу свою позицию, НЕТ, почти во всех случаях EF Core 6 или более поздняя версия будет гораздо лучшим выбором, чем Dapper.. Преимущества производительности Dapper на самом деле были превзойдены EF, что устраняет основной аргумент в пользу рассмотрения Dapper вообще.

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

Есть несколько сценариев, когда EF или правильный ORM могут быть проблематичными для команды разработчиков, обычно это кто-то новичок в программировании, который только что изучил SQL, а затем переходит на C#. Отсутствие знаний о наборе инструментов, как правило, не лучшая причина отказаться от него, если только вы не владеете альтернативой. Здесь следует прояснить: Dapper НЕ является альтернативой EF, Dapper — это альтернатива использованию интерполяции строк (или конкатенации) для создания необработанных SQL-запросов, и не более того.

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

Критерии использования Dapper:
Ваша команда понимает, как правильно использовать Dapper?
Свободно ли они владеют SQL и понимают причины, по которым следует избегать SELECT * и убедиться, что WHERE пункт правильно установлен?
Понимают ли они, как имена и типы свойств в указанных столбцах сопоставляются с тип который указан как ответ на запрос Dapper?
Ваша команда знает, как диагностировать проблемы с кодом Dapper?
Есть ли у них доступ к инструментам для тестирования и проверки необработанных SQL-запросов?
Понимают ли они, как модифицировать необработанный SQL для безопасного использования интерполяции?
Знает ли ваша команда, как диагностировать неэффективные запросы Dapper и исправлять их?
Вы понимаете SQL и применение бизнес-логики к схеме SQL.
Если нет, возможно, вам следует использовать EF, чтобы архитекторы могли инкапсулировать общие бизнес-выражения в C# в соответствии с принципами DRY вместо того, чтобы штамповать общие выражения SQL по всей кодовой базе.
Достаточно ли хорошо ваша команда понимает код, который Dapper написал для вас, чтобы знать, что он делает?
Все ли вы знаете, как читать SQL и как его отлаживать?
Разработчики, которым поручено исправить проблему во время выполнения (которая, скорее всего, возникнет в Dapper из-за отсутствия проверки типов компилятора), возможно, не написали ошибочный SQL или сопоставление объектов.
Ваша команда знает, как защитить учетные данные Dapper на клиентских машинах? > — То же самое и в EF, поэтому не подходит для сравнения…

Вот в чем загвоздка: с EF вы также можете выполнять необработанный SQL, и почти всегда это было возможно. Dapper против EF часто является круговым спором, большинство вопросов, высказанных в поддержку Dapper, рассматриваются сообществом EF/ORM как антипаттерны. Есть некоторое сходство с сравнением C++ и C#, C#/EF — это реализации высокого уровня, которые идут с некоторыми компромиссами производительности и конфигурации, чтобы уменьшить усилия и обслуживание. C++ и Dapper предлагают реализации более низкого уровня, которые требуют от вас гораздо большей ответственности за правильное управление кодом и памятью. Но в современных версиях EF ВСЕ функциональности и производительности Dapper были поглощены или воспроизведены в аналогичных функциях EF. Таким образом, аргумент больше не EF против Dapper, теперь это генерация запросов LINQ to SQL против необработанных строковых литералов SQL. EF предоставляет вам оба варианта в одном пакете.

Для выполнения необработанного SQL Dapper полностью превосходит оригинал. наследие выпуск EF6 (.Net Framework) с точки зрения предложения параметризации и очистки необработанных SQL-запросов. Альтернативой в EF был немного другой синтаксис, и вам приходилось вручную реализовывать параметры, поэтому синтаксис Dapper превосходит исходный EF6. SqlQuery(), но разницу в скорости выполнения сырого SQL иногда трудно измерить, Dapper иногда выигрывает, но это фотофиниш. EF Core перенял большую часть функций, которые отличали Dapper от EF, благодаря форматируемым строкам, а позже улучшил это предложение за счет прямой интерполяции параметров. Исследовать EF Core — SQL-запросы Больше подробностей. Если разница в одну цифру в миллисекундах окажет значительное влияние на ваше приложение, то, возможно, Dapper того стоит, но больше нет гарантии, что он превзойдет EF в буквальном разборе запросов sql, под капотом они оба используют одно и то же ядро ADO. Net runtimes и EF имеют дополнительные оптимизации, которые могут лучше производительность, чем Dapper (позже я обновлю ссылку на некоторые свежие исследования..) Единственное различие, которое, возможно, стоит учитывать, заключается в том, что из-за значительно уменьшенной функциональности dapper его библиотеки времени выполнения меньше и имеют несколько меньше зависимостей, но это все. Время выполнения и время разработки почти идентичны, если вы решите использовать необработанные SQL-запросы, закодированные в строковые литеральные переменные.

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

Для меня с архитектурной точки зрения EF, как вариант более высокого уровня, гораздо лучший выбор. Особенно для среднесрочного и долгосрочного управления проектами или продуктами. Как заметил Тим, мы должны убедиться, что мы можем поддерживать его в долгосрочной перспективе. ORM здесь легко выигрывает, главным образом потому, что «магические» строки сокращаются или полностью удаляются. Магия, о которой я говорю, — это необработанные операторы SQL. Если ваша схема НИКОГДА не изменится, то Dapper может сослужить вам хорошую службу после того, как вы вручную запишете все эти операторы SQL, но если ваша схема может быть изменения вы будете вынуждены вручную поддерживать ссылки на поля, таблицы и отношения в ваших операторах SQL (которые являются строками), чтобы соответствовать развивающейся базе данных и/или схеме объектов данных.

Ключевой особенностью ORM является то, что вы можете отделить схему бизнес-объекта от схемы данных и управлять отображением или интерфейсом между ними, если вам нужно, не затрагивая остальную часть вашей кодовой базы. Если вы не хотите управлять сопоставлением, то в EF изменения в модели вызовут ошибки компилятора, если на измененные элементы ссылаются в каких-либо запросах. Если вы выполняете простое переименование столбца, инструменты в вашей среде IDE могут автоматически реорганизовать все ссылки в вашем коде, которые будут включать ваши строго типизированные запросы, и вы можете вообще не увидеть никаких ошибок компилятора. С Dapper подобное изменение не будет обнаружено компилятором, вы обнаружите его только при тестировании или во время выполнения.

Еще одна особенность EF, которую нельзя упускать из виду, заключается в том, что в вашей логике доступа к данным может быть много очень похожих, но уникальных запросов к данным и команд. Если вам нужно указать необработанный запрос для таблицы или представления, вы можете сделать это один раз и сохранить это определение как выражение IQueryable. Это может быть база выражение, на которое другие, очень похожие, могут составлять дополнительные критерии или преобразования. Прямым эквивалентом этого в Dapper является выполнение базового запроса, извлечение всех данных в память и последующее выполнение дополнительных шагов. Обычный обходной путь Dapper для этой проблемы с производительностью — дублировать SQL и напрямую вводить тонкие изменения, которые могут потребоваться. Это классический пример запаха кода, который СУХОЙ принцип помогает нам избегать, особенно если необходимо внести изменения в некоторые или все производные запросы. (есть некоторые сторонние расширения построителя запросов, которые упрощают эту задачу, но не сравниваются с деревьями выражений.)

Производительность в производстве должна быть важнее, чем производительность в разработке.

Шикарное исполнение Быстрее чем EF для отдельных запросов, поскольку SQL-запрос уже составлен. Но это сопряжено со значительными затратами и риском для SDLC. Производительность команды и то, как быстро они могут реагировать на проблемы, поднятые клиентами, должны быть важнее, чем создание кода, который сложно поддерживать. Для многих команд дополнительные накладные расходы во время выполнения в EF являются достойным компромиссом по сравнению со временем и усилиями, необходимыми для поддержки необработанного SQL в большом проекте. По мере увеличения масштаба и сложности проекта, команды и схемы данных повышается и жизнеспособность EF (или других ORM) по сравнению с Dapper, но обычно с экспоненциальной скоростью.

Учитывая, что EF и EF Core содержат почти все функции, которые поддерживает Dapper (я не нашел ни одной, которая еще не поддерживается, но я открыт для предложений), и что сопоставитель объектов EF в .Net 6 и & 7 является намного эффективнее, чем в прошлом, не совсем уместно сравнивать EF с Dapper, Dapper — это значительно урезанная реализация EF, или EF — это Dapper с дополнительными функциями. Даже в 2019 году это было неправильным сообщением для более широкого сообщества, но особенно в 2022 году. Dapper — отличная альтернатива TableAdapters и прекрасное расширение традиционных интерфейсов данных ADO.Net, но отсутствие IQueryable поддержка деревьев выражений и задержка выполнения и составления базового SQL-запроса являются сильным фактором, ограничивающим производительность Dapper.

Я действительно не хотел вдаваться в это здесь, но следующее утверждение, вероятно, побудило меня написать это вообще.
Entity Framework в настольном приложении является серьезной проблемой безопасности.
Это действительно безосновательное утверждение, EF ни в коем случае не необходимость любые разрешения, кроме тех, которые вам также понадобятся для достижения тех же результатов с Dapper. EF и Dapper используют одно и тоже лежащий в основе ADO.Net DbConnection объект, который поставляется с теми же ограничениями для управления учетными данными. Получение права на безопасность пароля EF — это точно такой же процесс, как и для Dapper, поэтому, пожалуйста, не используйте это в качестве аргумента за или против какого-либо решения.

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

Имейте в виду, что Dapper создавался в то время, когда EF еще не был зрелым и Переполнение стека необходимо для снижения затрат на вычисления и повышения производительности сайта, который обрабатывает десятки миллионов запросов каждый день. Их схема данных не слишком сложна, и у них есть строгий процесс регрессионного и интеграционного тестирования перед развертыванием. Мы все хотим, чтобы наши решения были такими же успешными и востребованными, как Stack Overflow, и благодаря их новаторским усилиям другие наборы инструментов и ORM, такие как EF, развились для реализации интерполяции и разрешения параметров из строк SQL-запросов, которые кажутся естественными, и многих аспектов производительности. слишком. В 2022 году нам нужны свежие метрики и понимание альтернатив, прежде чем мы будем использовать старые аргументы или невежественно выборочную статистику в качестве основы для критических архитектурных решений.

по EF написаны целые книги. Это потрясающе, но это указывает на уровень сложности инструмента…

Я почти уверен, что книг по SQL больше, чем по EF… У меня есть полки с ними, и я прошел несколько уровней сертификации по MS SQL Server, но я все еще учусь каждый день. Итак, по логике Тима, я бы предположил, что SQL намного сложнее, чем EF, возможно, это хорошая идея для команд найти способ писать меньше SQL