@Chinook

Привет!

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

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

Но!

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

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

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

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

0

@Lamer George

Сталкивались. Мы делали именно так, вручную.

0

@Chinook

вручную - это string + string?

А почему так?

0

@Lamer George

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

Скорее всего, там создавался класс запроса с методами для установки выбираемых полей, таблиц, условий (тоже реализованных в виде классов), а на выходе формировалась итоговая строка.

0

@Chinook

Спасибо, интересно будет узнать.

0

@(Phantom)

Я использую как раз такой метод. У меня все запросы - это иерархия классов. Корень всего дерева это генерация запроса 'Select *', а FROM это виртуальная ф-ия. Дальнейшее усложнение запроса уводит в глуб дерева.
В результате чего проще сопровождать поняв эту органицзацию сопровождать. И еще один плюс меньше ощибок при наборе одинаковых данных, например имен таблиц, имен полей.

0

@Chinook

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

0