Самоуверенный совет

Шаблон репозитория — это воссоздание, а не (только) доступ к данным и гибкость

У вас когда-нибудь возникало исключение нулевого указателя после доступа к свойству объекта? Репозитории делают безопасным использование восстановленных сущностей.

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

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

Шаблон репозитория в первую очередь связан с абстрагированием воссоздания постоянных объектов домена.

Речь не об абстрагировании источника данных.

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

🔔 «Хотите больше таких статей? Подпишите здесь."

Гидратация объекта — это процесс заполнения пустого экземпляра объекта данными. Гидратация обычно скрыта от разработчика приложения с помощью EntityFramework Core (в .NET), Hibernate (в Java) или любого другого инструмента объектно-реляционного сопоставления (O/RM).

Настраиваем себя на неудачу — доступ к данным без репозитория.

📚 Посмотреть на GitHub.

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

Класс «Post» сопоставляется с таблицей «Posts», настроенной ниже.

Несмотря на то, что это надуманный пример, класс «Post» прекрасно демонстрирует, как работает частичная гидратация модели и почему это происходит.

Давайте проиллюстрируем проблему с частичной гидратацией.

Обратите внимание, что мы выбираем только некоторые свойства при выполнении db.Posts.Select(). Это возвращает сообщения только с Id и Title гидратированными.

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

Делая что-то столь же невинное, как попытка узнать имя автора, вы взрываете все приложение…

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

🔔 «Хотите больше таких статей? Подпишите здесь."

Почему происходит частичное увлажнение модели.

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

Неопытные разработчики с O/RM или выборкой данных обычно прибегают к возврату частичных моделей.

К счастью, преодолеть частичную гидратацию из-за непрактичных моделей легко.

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

Репозитории в помощь.

В приведенном ниже репозитории представлен метод для извлечения полных объектов Post и другой, настроенный для извлечения только подмножества значений в базе данных и сопоставления их с новым специализированным классом PostTitle.

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

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

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

Только открывая репозиторий, а не, например. DbContext (по сути, оболочка для соединения с базой данных), вы гарантируете, что клиенты будут делать только то, что задумано.

🔔 «Хотите больше таких статей? Подпишите здесь."

Прощальные слова.

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

Основное внимание в репозитории уделяется воссозданию сущностей. Обеспечить клиентам безопасный доступ ко всем свойствам, предоставляемым сущностью, и не беспокоиться о том, «может быть, это свойство имеет значение null?»

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

Давай останемся на связи!

Получайте уведомления о похожих статьях, подписавшись на информационный бюллетень здесь и проверьте Канал YouTube (@Nicklas Millard).

Подключиться к LinkedIn.

Ресурсы для любознательных