Привет!

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

Грядет переписывание этой кучи мусора, поэтому я хотел бы локализовать создание query в одном месте. Для меня очевидно (:-)), что такой объект = composit + interpreter, мы в произвольном порядке загоняем туда условия, потом получаем строку, представляющую из себя query. Я, собственно, уже продумал структуру и все такое.

Но!

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

Во-вторых, возможно, это не самый лучший путь, и кто-то знает лучший.

Собственно, вопросы: кто-нибудь про такой подход слышал? кто-нибудь с такой проблеммой сталкивался?

Заранее благодарен!

Цитата(chinook @ 20.5.2005, 19:33)

Собственно, вопросы: кто-нибудь про такой подход слышал? кто-нибудь с такой проблеммой сталкивался?

Слышать не слышать, но сталкиваться - сталкивался. И более того, реализовывал.

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

• Attribute
• Value
• Query
• Expression

Описатели аттрибутов не зашиты в код и хранятся отдельно (в базе, в XML, в проперях - неважно). Описатель содержит такие сведения: имя таблицы/столбца, тип данных, имя атрибута и плюс еще всякие флаги.

Value - это иерархия типизированных описателей значений, которые знают, как представлять себя в базе и на экране.

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

Query - это надстройка над Expression, которая может включать дополнительную информацию о порядке сортировки, диапазоне поиска и пр.

Важный момент: в этих интерфейсах нет ни намека на SQL, потому что клиенту об этом знать совершенно необязательно. На сервере эти интерфейсы расширены до SqlExpression и SqlQuery, соответственно, и у них есть методы, специфические для пострения собственно выражений SQL.

Вот в общих словах и весь подход. У меня - работает.

Да, там есть еще один интересный момент, связанный с поддержкой разных типов СУБД. Там фишка в том, что выносить конструкции SQL в ресурсы очень неудобно, потому что при написании/отладке хорошо видеть, что именно у тебя происходит. Поэтому тексты шаблонов у меня зашиты прямо в сорцах. А чтобы иметь возможность менять синтаксис в зависимости от СУБД, я создал базовый класс Flavored, и все прочие классы, которые содержат код SQL, унаследованы от него.

У этого класса есть два метода , setFlavor(String flavor) и getFlavored(String str). Первый используется при инициализации класса, чтобы установить версию, например, "postgres". А вот когда приходит время собственно генерировать запрос, то используется примерно такой код:

Код

private static String sortClause = "order by $1 $2"; private static String sortClausePostgres = "order by lower($1) $2 "; private String getSortClause() // допустим, в постгресе порядок сортировки по умолчанию чувствителен к регистру, а мы хотим сделать наоборот { ...   String template = getFlavored(sortClause); ... }

А внутри происходит следующее: когда вызывается getFlavored(), он использует рефлексию и ищет имя переменной, которая соотвествует переданной строке. В данном случае это переменная sortClause. После этого он присоединяет к имени переменной ранее установленный тип базы (postgres) и ищет переменную sortClausePostgres. Если таковая находится, он возвращает ее значение, если нет - то возвращает исходную строку.

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

ЗЫ. А ты чего до сих пор не зарегистрируешься? Шестым чувством чувствую, что мы с тобой земляки

Спасибо за подробный ответ!

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

А вот дальше надо составить собственно запрос. Пока это решается компонованием строки в зависимости от условий (таблиц, подзапросов, полей для связывания и т.п.).

Я не собиралься замахиваться на такого монстра, как у тебя :-) Забумывалось написать класс, не привязанный к определенной структуре данных, который может принимать:
1. Поля для select
2. таблицы для from
3. поля для where с условием связывания (=, *=, >...) и условием обязательности (or and)
4. поля для having
5. поля для order by

При этом 1, 2, 3 могут быть тем же классом (т.е. вложенные подзапросы - у нас Oracle, который это понимает).

Преимущества такого подхода:
1. все построение запросов в одном месте
2. нет определенного порядка добавления элементов (а то в полупостроенном запросе приходится вставлять новый подзапрос в группу from - выглядит ужасно)
3. Код бизнес-классов не захламляется всякими строками с кусками запроса (ну, это производное).
4. этот класс (скорее - пакет) можно будет использовать к любом приложении (по крайней мере с ораклом)

Почему, собственно, кажется это целесообразным:
1. interpter: шаблон для перевода чего-либо с одного языка на другой. Т.е. перевод на sql - сам Бог велел.
2. composit: обход дерева, в которое превращается запрос - все точно по документации.

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

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

Цитата

ЗЫ. А ты чего до сих пор не зарегистрируешься? Шестым чувством чувствую, что мы с тобой земляки

Зарегистрировался. Шестым!?!?! Ну, возможно :-) Я вообще-то из Воронежа, живу в Ванкувере.





Добавлено @ 01:54
О, блин, Калгари! А я что-то затормозил :-) Ну да, точно, чинук - это, слава Богу, у вас :-)

Может быть еще вот эта статья Скотта Эмблера (из Торонто!!! ) поможет - http://www.ambysoft.com/persistenceLayer.pdf. Она посвящена архитектуре библиотеки объектно-реляционного отображения, но идеи похожи.

tux
Спасибо за линк. Обязательно прочту.

А может стоит использовать Hibernate
Зачем изобретать велосипед

Может, и стоит, просто я его пока не знаю

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

Да и еще, небольшое дополнение:
Для обеспечения нормальных транзакций и упрощения работы с транзакциями
очень хорошо использовать Spring в одной связке с Hibernate.

В данном случае это приведет к необходимости создания слоя хранимых объектов и преобразования запросов из SQL в объектные запросы на HQL. Не уверен, что преобразование всегда можно будет выполнить один в один. В частности это зависит от того, в каком объеме используются функции, характерные только для данной используемой СУБД. Хотя генератор запросов на HQL в Hibernate уже есть и если запросы не очень сложные и их не очень много возможно что действительно использование Hibernate оправдано.

Если очень надо могу помочь примером "Spring + Hibernate"
Но придется денек подождать т.к. мне его надо будет сделать.

То, что у меня уже есть к сожалению дать не могу т.к. это текущий проект.
Добавлено @ 11:07

Цитата(tux @ 23.5.2005, 10:53)

В данном случае это приведет к необходимости создания слоя хранимых объектов и преобразования запросов из SQL в объектные запросы на HQL. Не уверен, что преобразование всегда можно будет выполнить один в один. В частности это зависит от того, в каком объеме используются функции, характерные только для данной используемой СУБД. Хотя генератор запросов на HQL в Hibernate уже есть и если запросы не очень сложные и их не очень много возможно что действительно использование Hibernate оправдано.

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

Цитата

Где: Vancouver, BC, Canada

Канадская диаспора на русском форуме

Сори за офтоп

Domestic Cat )



Сорри, сразу не увидел но обсуждение Hibernate
ведется еще и в этом топике
http://forum.vingrad.ru/index.php?showtopic=31813

ИМХО использовать Hibernate и если есть возможность все запросы вынести на сторону БД

Цитата

Насчет сложности запросов, то средствами Hibernate можно делать запросы любой сложности.

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

Цитата(tux @ 23.5.2005, 11:28)

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

За универсальность надо платить

Понятно, что собственная реализация работы с БД (если все правильно сделано)
может быть лучше чем универсальный подход, но в этом случае не надо забывать сколько времени и сил уйдет на эту собственную реализацию.
+ Суппорт, стоит внести небольшие изменения в модель данных или перейти на другую БД
как придется переписывать массу запросов, что в Хибернейте решается простым переписыванием маппингов (и то это придется делать только в том случае если произошли изменения в модели)