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

TL; DR: Это микро-ORM, по которому вы, возможно, так сильно мечтаете. 👀 Пожалуйста, не пропустите драгоценности! 👑

Dapper - это легкая микро-ORM для .NET, на которой уже много лет работает популярный сайт StackOverflow. Он был разработан, чтобы намеренно решить проблему производительности сайта StackOverflow в первые дни его существования.

Принимая во внимание, что RepoDb - это новая гибридная микро-ORM для .NET, предназначенная для обслуживания недостающих частей как микро-ORM, так и макро-ORM (также называемых полными ORM). Он также был разработан, чтобы упростить процесс кодирования микро-ORM и в то же время сохранить производительность и эффективность приложения.

Оба они быстрые, эффективные и простые в использовании. Они также обращаются к различным вариантам использования. Однако мы надеемся, что этот блог поможет вам выбрать RepoDb в качестве инфраструктуры ORM при разработке нового решения для вашего бизнеса.

Пожалуйста, позвольте себе сразу проверить или прокомментировать, если вы думаете, что мы сделали эту страницу предвзятой для RepoDb.

Пожалуйста, не пропустите заключение в конце этой статьи. 👇

Я Майк, автор RepoDb, участник открытого кода и технический блоггер. В настоящее время я работаю старшим разработчиком приложений Offshore Wind в Orsted A / S, датской компании по возобновляемым источникам энергии, которая была названа самой устойчивой компанией в мире. Мы интегрируем многомиллионные и / или миллиарды наборов данных между нашими поставщиками и нашими организациями (разными способами). Я здесь, чтобы поделиться с вами тем, что я сделал. Я много работал над улучшением пространства доступа к данным в .NET. Я лично прошу вашей поддержки по отношению к этой библиотеке. Надеюсь, вы поделитесь, ведете блог и пользуетесь им.

Опыт разработки 🙉

PTP: Изображение выше взято из этой ссылки, в которой оно связано с этой страницей.

Нам всем понравилась гибкость и управляемость во время разработки, особенно если мы заинтересованы в производительности и эффективности. Это основная причина, по которой мы выбираем Dapper micro-ORM вместо Entity Framework.

Однако такая микро-ORM требует, чтобы вы писали SQL во всех действиях, связанных с БД.

Вам всегда нравилось писать SQL? Если да, то Dapper вам подходит 😀. В противном случае вы в конечном итоге засорете свой код такими избыточными текстами SQL по всему репозиторию или DAL.

Давайте посмотрим на образец кода для запроса данных ниже.

Как насчет вставки новой записи?

Другие операции, такие как Удалить, Объединить, Обновить (многие другие), также присутствуют, чтобы помочь вам с вашей гибкостью и управляемостью. Также важно отметить, что RepoDb может выполнять все, что Dapper может выполнять в необработанном SQL.

При использовании RepoDb опыт разработки такой же, как и в Dapper, с гораздо большей гибкостью, контролем, беглостью и организацией.

Вы можете прочитать больше в разделе «Опыт кодирования и сравнения».

Основные характеристики, производительность 🚀 и эффективность ⚡️

Многие придерживаются такой идеологии: «Если вы предпочитаете производительность, выбирайте Dapper, в противном случае - Entity Framework». В этом пространстве он кажется близким, поскольку это всегда Entity Framework или Dapper.

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

RepoDb, это самая быстрая и самая эффективная ORM в .NET на сегодняшний день (как необработанный, так и плавное выполнение). Достаточно причин, если вам важны производительность и эффективность. Официальный результат можно найти здесь.

И «производительность», и «эффективность использования памяти» являются главной особенностью этой библиотеки. Он был реализован с учетом «Dapper-in-mind», что дает нам точку отсчета для дальнейшего улучшения показателей на всем протяжении разработки.

Реальная поддержка «массовых операций» на лету ⚡️

Это нишевая функция, которая отсутствует в большинстве микро-ORM и полных ORM до этой библиотеки. Есть некоторые бизнес-сценарии, в которых требуется эта функция, позволяющая очень быстро переносить данные с клиента на сервер базы данных. Да, мы говорим о самом быстром способе выполнения Вставить, Удалить, Объединить и Обновить.

В Dapper вам нужно написать способ ADO.NET, используя для этого класс SqlBulkCopy.

В RepoDb всего можно добиться всего одной строчкой кода. Вам даже не нужно преобразовывать модели в объект «System.DataTable», что приводит к более быстрой и эффективной обработке.

Ниже приведен образец теста, в котором сравниваются операции «Bulk» и «Batch» с упакованными SQL-операторами. Это снизило 48 секунд до 1,74 секунды для 200 тыс. Строк с 5 столбцами.

Если для аргумента isReturnIdentity установлено значение true, автоматически сгенерированное значение идентификатора будет возвращено моделям.

А как насчет объединения нескольких строк?

В Dapper вам необходимо создать табличные параметры (TVP), используя определяемые пользователем типы (UDT), и создать настраиваемые хранимые процедуры, которые принимают это в качестве параметра. Это выполнимо, но утомительно и требует дополнительного оперативного обслуживания.

В RepoDb вам нужно вызвать только один метод.

Тот же вызов метода также поступает в BulkUpdate и BulkDelete. Представьте себе усилия, которые вы сэкономили при внедрении.

Установив для параметра usePhysicalPseudoTempTable значение «true», вы разрешаете RepoDb создавать физическую временную таблицу перед переходом в фактическую таблицу. Этот сценарий полезен, если вам важнее производительность, а не безопасность потоков.

Полная поддержка атомарных, пакетных и массовых операций ⚡️

Большинство разработчиков игнорируют «когда что использовать» в определенных бизнес-сценариях. Также важно всегда учитывать вашу текущую ситуацию, независимо от того, используете ли вы локальную / облачную версию, Windows / Linux, низкие / высокие характеристики.

Вы должны как минимум учитывать следующее:

  • Сеть / Задержка
  • Инфраструктура
  • Число столбцов
  • так далее

Для дальнейшего понимания ниже представлена ​​общая картина различий между этими операциями.

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

Вы и ваша команда должны определить диапазон «размера пакета» (например, от 30 до 1000), который вы можете использовать при сохранении, обновлении или удалении данных по пакету.

  • Любые строки, которые ниже номера нижней границы этого диапазона, должны использовать «атомарные» операции.
  • Для всех чисел в диапазоне эталонного теста необходимо использовать «Пакетные» операции.
  • Для чисел выше верхнего предела вашего эталонного теста «размера партии» необходимо использовать «Групповые» операции.

Приведенный ниже код представляет собой образец для "атомарного" вызова.

Приведенный ниже код представляет собой образец для «пакетного» вызова.

Ниже приведен пример кода для массового вызова.

Навальный - кажется, самый быстрый способ, но не всегда лучший. Мы рекомендуем использовать «Массовый» только в том случае, если вы работаете с несколькими тысячами строк, в противном случае используйте «Пакетный».

В любом случае такие операции поддерживаются RepoDb «из коробки». В случае Dapper и / или других ORM вам придется потратить время на написание собственной реализации и последующее ее сопровождение. Представьте себе усилия, которые вы сэкономили во время разработки, обращаясь к реальным бизнес-сценариям.

Поддержка 2-го уровня кэша 🐢 → 🐇

Это одна из очень важных функций, отсутствующих во всех других ORM, с которыми я (как автор) до сих пор сталкивался. Это очень важно в том смысле, что не все таблицы в наших базах данных активно меняются. Фактически, 30% вашей таблицы (возможно) активны, а остальные 70% - это просто таблицы поиска или статические таблицы (и т. Д.).

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

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

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

По умолчанию кеш хранится в памяти через объект «RepoDb.MemoryCache». Вы можете переопределить это, создав свой собственный класс, реализующий интерфейс «ICache», и передав его аргументу «cache».

Чтобы узнать больше о кешировании, посетите нашу официальную документацию.

Гибкость преобразований свойств 👌🏻

Вы можете застрять в какой-то момент времени, и вам потребуется обработать преобразование свойств при извлечении данных «в» или «из» из базы данных.

Такая функция важна для того факта, что не все типы данных из базы данных могут быть автоматически принудительно преобразованы самой .NET (например, XML, JSON как текст и т. Д.). В таких случаях вам приходилось писать конвертеры или какие-то трюки, которые могут прийти в голову.

С помощью этой функции легко организовать вещи и собрать все в одном месте.

Допустим, у вас есть таблица «[продажи]. [Клиент]», в которой есть столбец «Адрес» типа «NVARCHAR (MAX)». Тогда вы хотите, чтобы это была «адресная» модель при чтении данных из базы данных. На стороне клиента у вас есть класс «Клиент», который имеет свойство «Адрес» настраиваемого типа «Адрес».

Такой сценарий может быть обработан обработчиком свойств ниже.

Вам просто нужно реализовать класс, реализующий интерфейс «IPropertyHandler‹ TInput, TOutput ›», и сопоставить его с целевой моделью (то есть с клиентом).

При такой реализации любые вызовы операций (например: Запрос, Вставка, Обновление, Слияние и т. Д.) Всегда будут запускать методы в классе «CustomerAddressPropertyHandler».

Вышеупомянутый сценарий - это преобразование типа в тип. Любые другие сценарии можно обрабатывать, как показано ниже.

  • Обработка денежных полей
  • Преобразование свойства Kind поля System.DateTime
  • Преобразование типа данных (например, String-to-Guid, Guid-to-String)
  • Так далее

На самом деле количество сценариев, которые может обрабатывать обработчик свойств, не ограничено.

Опыт кодирования и сравнения 🙉

Одним из преимуществ использования этой библиотеки является «Выражение запроса» и «Беглость».

Когда вы используете эту библиотеку, ваш опыт представляет собой комбинацию Dapper и Entity Framework.

Да, это так же просто, как Dapper при открытии соединения и так же просто, как Entity Framework при выполнении операции. Вам не нужно писать SQL и промежуточный объект, такой как «DbContext», при взаимодействии с базой данных.

Пользователь заявляет: мне нужен Dapper, потому что мне вообще понравился оператор SQL или выполнение SP.

Что ж, в RepoDb есть следующие методы (ExecuteNonQuery, ExecuteScalar, ExecuteQuery, ExecuteQueryMultiple и ExecuteReader), которые могут дать вам тот же опыт, что и Dapper.

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

Качество библиотеки 💥✔️

Что ж, Dapper на рынке уже почти 9 лет, и в настоящее время он широко используется. Несомненно, эта библиотека качественная по своему назначению.

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

RepoDb запускает различные критически важные системы в производственной среде в нашей организации (например, предоставляет самое быстрое решение для обработки данных, различные основные API-интерфейсы и т. Д.).

Имея это в виду, RepoDb - это высококачественная библиотека ORM.

Другие элементы в этой ORM ♻️

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

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

Общий вывод 👋

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

Простота

Dapper легкий, но он перетащит вас на более сложный уровень разработки кода. Писать необработанный SQL всегда утомительно, и его трудно поддерживать из-за того, что он несовместим с компилятором. Кроме того, чтобы получить необходимое задание, вам необходимо реализовать необходимые функции. RepoDb - это простой в использовании ORM с достаточным набором функций, на котором вы можете играть.

Производительность

RepoDb быстрее, чем Dapper, достаточная причина выбрать эту библиотеку, если единственным фактором является производительность.

Эффективность

RepoDb более эффективен, чем Dapper (то же самое, что и в Performance). Это также самая эффективная библиотека ORM в .NET.

Опыт

С RepoDb разрабатывать код проще и быстрее. Он имеет богатый набор функций, который можно использовать сразу (например: кэш 2-го уровня, методы Fluent). Это поможет вам, как разработчику, быстро и чисто доставить больше кода.

Возможности

В RepoDb наличие необходимых функций в пространстве микро-ORM очень поможет вам в разработке.

Такие функции, как массовые и пакетные операции, обработчики свойств, кэш 2-го уровня, деревья выражений, множественные запросы и подсказки, являются наиболее часто используемыми функциями. Основные болевые точки в Dapper отсутствуют.

~ Спасибо, что прочитали эту статью. ~