Как начать использовать шаблон спецификация?

Question

[Михаил]

У меня есть репозитории в которых я получаю данные с api и базы. Снаружи манипулирую только сущностями (моделями). Возникла необходимость в универсальном задании правил выборки. Проще говоря, мне нужно указывать условия для метода findBy($criteria) которая внутри в зависимости от типа ресурса будет конвертироваться в формат условия который понимает ресурс.
Я вроде нашел то что надо: https://github.com/K-Phoen/rulerz Подумал что смогу написать конвертер условий в понятный формат внутренних ресурсов. Но там абстракция в абстракции основанная на абстракции и пока что не могу понять как правильно начать использовать и подходит ли под мои задачи эта либа.

Возможно ли реализовать задачу с помощью нее? Не сильно сложно ли будет реализовать конвертер для ресурсов?
Внутри нее используется hoaproject/Ruler, возможно именно его нужно использовать?

Поделись опытом кто работал с ней...

Answer 1

[AlexHell]

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

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

более конкретно по вашему вопросу не ясно вот это
"Проще говоря, мне нужно указывать условия для метода findBy($criteria) которая внутри в зависимости от типа ресурса будет конвертироваться в формат условия который понимает ресурс."
что есть "в зависимости от типа ресурса" - какие виды ресурсов?
вообще у вас должна быть начинка "реальной работы", для случая спецификации: когда в вашем findBy вызываются специфичные методы которые в спецификации есть, возможно надо и с другими шаблонами/сущностями сгруппировать, например из спецификации вызывать конкретный метод одного из полиморфных преобразователей (IImplementer, Implementer1, Implementer2) или полиморфный билдер, допустим в методе Invoke(IImplementer) вашей спецификации будет дергаться кокнертные методы IImplementer которые для случая с API будут готовить одну строку по http а для случая с sql бд будут генерить sql строку, аппендить ее к результату или аналогичное

Comments

[Михаил]

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

[AlexHell]

findByCustomerEmail, и все аналогичные - это из паттерна Repository для доступа к БД применяется, т.е. конкретный getter + параметры, так тоже делают часто, и это более ООП стиль.
Спецификация для доступа к БД не единственный вариант, и зачастую более запутанный или динамический, в том числе изза множества промежуточных классов повышающих уровнень indirection, да еще и генерация текста sql что багоопасно.

[Михаил]

AlexHell, Я не решился пока реализовывать полное DDD по нескольким причинам и среди нереализованного - репозитории инфраструктуры, репозитории сразу знают откуда что брать и сами берут.