Да немного сумбурно получилось. Но я не призываю ничего переизобретать.
Речь про то что надо думать о зависимостях в проекте.
Я тут капитана очевидность включу не на долго:
Обычно создается класс наследующий репозиторий из ОРМ и имплементирующий наш интерфейс.
Но интерфейс определяется в самом приложении. Нельзя использовать интерфейс из ОРМ. Т.к. это будет нарушение принципа инверсии зависимостей.
Формулировка:
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Первый пункт как раз об этом.
кэп офф.
И это конфликтует с Вашим выводом:
Уважаемые коллеги, не пытайтесь абстрагироваться от выбранного Вами фреймворка! Как правило, фреймворк уже предоставляет достаточный уровень абстракции. А иначе зачем он нужен?
Я это к тому что — не стоит выдавать такие утверждения. В интернетах полно неопытных ребят. И вы можете наблюдать их в комментариях к статье тоже. И если они без понимания проблемы рванут прикручивать ваше решение — это до добра не доведет.
Автор не потрудился почитать описание паттерна Репозиторий, какие проблемы он решает, а так же не понял где у него проблема в принципе(в разных источниках). Хотя с QueryObject еще не все так плохо и они вполне жизнеспособны, но в другом месте.
Начну с хорошего:
В папочке с QueryObject в принципе легче ориентороваться.
Их проще писать, проще внедрять в сервисы.
Проще вводить новые версии.
Проще моки писать в тестах — не надо все зависимости репозотория переопределять.
Еще отлично встроятся в read часть вашего приложения, если вы запилили CQRS.
На этом все.
Теперь о плохом. Репозиторий.
В первую очередь Репозиторий — это интерфейс коллекции доменных объектов. Он абстрагирует нашу систему хранения данных. А ORM — Это вообще не про это. ORM про маппинг сток из базе на объекты.
Эти 2 паттерна решают разные проблемы и используются по разному.
Использование класса из ORM вместо интерфейса репозитория — это циклическая зависимость в вашем коде. Если вы захотите заменить систему хранения данных — вы попали. Хотя в некоторых случаях такое упрощение в полне себе решение. Никому эти репозитории в блоге или сайте визитке не нужны.
Пример из реального проекта.
Одним из решений для задачи — было запилить EventSourcing. В качестве первого решения, было решено использовать MySQL как хранилище данных. Так было проще начать.
Со временем оказалось что:
все события просто напросто физически не влезут в него, хард не резиновый.
использовать MySQL финансово не выгодно.
По этому было решено переехать на DynamoDB. Если бы я использовал использовал репозитории ORM — мне бы пришлось выпилить его полностью. А так — я просто запилил новый класс, имплементировал пару методов и готово — в продакшин.
Это то что касается Репозиториев.
Теперь про количество методов в Репозиториях.
Репозиторий используется совместно с ОРМ. Сейчас мы обратим внимание на то что он используется именно для Маппинга Доменных Объектов. И возвращает коллекцию доменных объектов.
Большинство методов, от которых растет Репозиторий и на которые грешит автор — это методы для чтения данных.
Так вот. Если вы подумали хорошо, когда проектировали ваше приложение — то наверное запилили бы CQRS. Тогда в вашем слое C были бы UseCase, которые использовали бы Репозитории с ОРМ.
А в слое Q были бы ваши QueryObject или что по проще, без ОРМ. Он там нафиг не впился.
Другими словами — Репозитории с ОРМ вам нужны там, где бизнесс логика. Там где просто вывод данных — вам и ОРМ не впилась, используйте SQL.
Вы можете посмотреть видео Marco Pivetta "Doctrine Best Practices". Не надо плеваться что это Доктрина, принципы в ОРМ одни и те же.
А нафиг оно вообще все надо? Зачем усложнять?
Все эти дела с перозиториями, орм, интерфейсам, и т.д. и т.п. порой появляются на ровном месте.
Ваше решение должно быть обосновано, внимание, ТРЕБОВАНИЯМИ К ПРОЕКТУ, а не личными хотелками.
Если вы пишите блог — не надо там квери обьекты городить или отдельные репозитории вводить. Берите репозиторий ОРМ и в продакшин. А если у вас что-то больше — обязательно проверьте не будет ли меняться система хранения данных в конкретной части приложения. Ведь мы можем писать в мускуль, а клиенту отдавать из редиса. И то и то можно спрятать в репозитории. И когда прийдет время заменить имплементацию на что-то еще — вы не будете плакать.
Для лучшего понимания рекомендовал бы посмотреть видео Евгения Кривошеева "Осознанность проектирования" и "Как не угробить архитектуру сразу же". Можно найти тут же на хабре. Там еще интересное.
Да немного сумбурно получилось. Но я не призываю ничего переизобретать.
Речь про то что надо думать о зависимостях в проекте.
Я тут капитана очевидность включу не на долго:
Обычно создается класс наследующий репозиторий из ОРМ и имплементирующий наш интерфейс.
Но интерфейс определяется в самом приложении. Нельзя использовать интерфейс из ОРМ. Т.к. это будет нарушение принципа инверсии зависимостей.
Первый пункт как раз об этом.
кэп офф.
И это конфликтует с Вашим выводом:
Я это к тому что — не стоит выдавать такие утверждения. В интернетах полно неопытных ребят. И вы можете наблюдать их в комментариях к статье тоже. И если они без понимания проблемы рванут прикручивать ваше решение — это до добра не доведет.
Самое печельное, что они искренне уверены, что они знают как надо использовать фреймворк.
http://sergeykorol.ru/blog/competence/
Автор не потрудился почитать описание паттерна Репозиторий, какие проблемы он решает, а так же не понял где у него проблема в принципе(в разных источниках). Хотя с QueryObject еще не все так плохо и они вполне жизнеспособны, но в другом месте.
Начну с хорошего:
На этом все.
Теперь о плохом. Репозиторий.
В первую очередь Репозиторий — это интерфейс коллекции доменных объектов. Он абстрагирует нашу систему хранения данных. А ORM — Это вообще не про это. ORM про маппинг сток из базе на объекты.
Эти 2 паттерна решают разные проблемы и используются по разному.
Даже Фарулер говорит:
Data Mapping Layer — это как раз таки Ваша ORM.
Использование класса из ORM вместо интерфейса репозитория — это циклическая зависимость в вашем коде. Если вы захотите заменить систему хранения данных — вы попали. Хотя в некоторых случаях такое упрощение в полне себе решение. Никому эти репозитории в блоге или сайте визитке не нужны.
Пример из реального проекта.
Одним из решений для задачи — было запилить EventSourcing. В качестве первого решения, было решено использовать MySQL как хранилище данных. Так было проще начать.
Со временем оказалось что:
По этому было решено переехать на DynamoDB. Если бы я использовал использовал репозитории ORM — мне бы пришлось выпилить его полностью. А так — я просто запилил новый класс, имплементировал пару методов и готово — в продакшин.
Это то что касается Репозиториев.
Теперь про количество методов в Репозиториях.
Репозиторий используется совместно с ОРМ. Сейчас мы обратим внимание на то что он используется именно для Маппинга Доменных Объектов. И возвращает коллекцию доменных объектов.
Большинство методов, от которых растет Репозиторий и на которые грешит автор — это методы для чтения данных.
Так вот. Если вы подумали хорошо, когда проектировали ваше приложение — то наверное запилили бы CQRS. Тогда в вашем слое C были бы UseCase, которые использовали бы Репозитории с ОРМ.
А в слое Q были бы ваши QueryObject или что по проще, без ОРМ. Он там нафиг не впился.
Другими словами — Репозитории с ОРМ вам нужны там, где бизнесс логика. Там где просто вывод данных — вам и ОРМ не впилась, используйте SQL.
Вы можете посмотреть видео Marco Pivetta "Doctrine Best Practices". Не надо плеваться что это Доктрина, принципы в ОРМ одни и те же.
А нафиг оно вообще все надо? Зачем усложнять?
Все эти дела с перозиториями, орм, интерфейсам, и т.д. и т.п. порой появляются на ровном месте.
Ваше решение должно быть обосновано, внимание, ТРЕБОВАНИЯМИ К ПРОЕКТУ, а не личными хотелками.
Если вы пишите блог — не надо там квери обьекты городить или отдельные репозитории вводить. Берите репозиторий ОРМ и в продакшин. А если у вас что-то больше — обязательно проверьте не будет ли меняться система хранения данных в конкретной части приложения. Ведь мы можем писать в мускуль, а клиенту отдавать из редиса. И то и то можно спрятать в репозитории. И когда прийдет время заменить имплементацию на что-то еще — вы не будете плакать.
Для лучшего понимания рекомендовал бы посмотреть видео Евгения Кривошеева "Осознанность проектирования" и "Как не угробить архитектуру сразу же". Можно найти тут же на хабре. Там еще интересное.