Архитектура CMS. Модель данных. Часть 3

[boolive]

А где применяется? И в каких моментах отличия?

[clops]

с теоретической точки зрения — все отлично,
с практической — «ебануться» — слишком наворочено а оттуда сложный learning curve — no profit

[boolive]

:)) достаточно уметь представлять предметную область (данные) объектно, чтоб условия для поиска составлять. Тогда всё само собой понимается. ;)

[m007]

Такой же подход построения условий используется в Hibernate. И нет никаких сложностей.

[sse]

Поставил плюс.
Однако в NHibernate это — только как один из вариантов, используемый для достаточно простых запросов. Для более сложных гораздо приятнее не городить кучу синтаксического мусора, а писать прямо на HQL.

[sse]

Я думаю, что сказав А, стоит сказать и Б :) Показанная в посте система построения запросов — это пример QBA — «Query By API»:

… запросы конструируются путем использования объектов-запросов, обычно примерно в такой форме:
Query q = new Query();
q.From(«PERSON»).Where( new EqualsCriteria(«PERSON.LAST_NAME», «Smith»));
ObjectCollection oc = QueryExecutor.execute(q);

Здесь запрос основывается не на пустом «шаблоне» выбираемого объекта, а на наборе «объектов-запросов», которые совместно используются для определения объекта в стиле команды, предназначенной для выполнения над базой данных. Несколько критериев комбинируется путем использования некоторой конструкции, обычно соединяющей через «And» и «Or» объекты, каждый из которых содержит уникальный объект-критерий, задающий часть условия выборки. К концу запроса могут быть добавлены вызовы объектов фильтрации/манипулирования, такие как «OrderBy(field-name)» или «GroupBy(field-name)». В некоторых случая эти вызовы методов в действительности ведут в объекты, конструируемые программистом и явно связываемые между собой...

Отсюда

[boolive]

Тогда ещё не подумал об этом, а ведь использование шаблнчиков условий будет даже очень удобным да и в целях оптимизации тоже. Но почему-то вместо развития объектного подхода к составлению условий, думаю сейчас в направлении создания текстового описания — а-ля SQL3 :)

[sse]

Я думаю, что ваш путь с текстовым описанием будет куда сложнее. Оно вам надо? :)

Парсер «синтаксис -> AST», а затем AST-процессор — это не та штука, которую можно написать и забыть — как правило, это одна из самых сложно тестируемых частей. Даже у MS в ее T-SQL встречаются баги разбора SQL-команд.

Куда проще и понятнее Query Objects, которые позволяют строить AST напрямую, пользуясь возможностями самого языка программирования. Понятно, что для сложных запросов этот процесс будет выглядет монстровато, но на практике 90% — более-менее простые запросы.

Далее, Query Object может отлично скрыть за своим API манипуляции нижнего уровня, paging, самостоятельно оптимизировать запросы и т.п.

Я бы сначала пошел таким путем, а затем прикрутил к нему text query, если понадобилось бы, благо одно хорошо уживается с другим. Рекомендую вам посмотреть на HQL и Criteria API из Hibernate.

Тем не менее, решать-то вам :) В любом случае, удачи.

[boolive]

Первый путь уже пройден, разве что только самой оптимизацией его заниматься со стороны его использования и генерации sql.
Я с вами не спорю, делать парсер непросто да и средствами php не эффективно. Но проработав текстовое описание запроса, можно выявить более оптимальный и более гибкий подход к описанию средствами языка программирования. Надеюсь :) Hibernate же через чур мудреный, чтоб с него брать пример.

[sse]

Как мне кажется, текстовая форма — это только одна из форм, причем не самая удачная (с точки зрения программиста). Хотя ее проработка может быть хорошим «трамплином», чтобы перейти к более общему пониманию формы и механизма запросов в репозиторий объектов.

Второе. В Hibernate есть все, что стоит иметь в хорошем ORM уровня Enterprise :) Совершенно необязательно переносить это все к себе, но кое-что иметь крайне полезно.

К сожалению, обсуждение этого выходит за рамки поста, потому как тут вы поднимали тему исключительно паттерна Query-Object.

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

[boolive]

Не будем разворачивать новых тем, только хочется от вас узнать, на что именно стоит обратить внимание у Hibernate?

[sse]

HQL — корпоративный стандарт в мире Java (кроме Hibernate, как минимум TopLink и EclipseLink его поддерживают).

На что конкретно вам смотреть, не могу сказать, потому что не очень хорошо представляю, что вы хотите найти; но вот тут в блоге code-inside-out.blogspot.com/2009/01/25-ormapper.html перечислено то, что поддерживается в NHibernate и полезно иметь в ORM.

[sse]

Сорри, отправилось раньше.

Обратите внимание на NHibenrate Criteria API

[bioroot]

О майн год! Даз ит Битрикс?! %)))

Вы бы эту ссылочку поперёд всего выкатили: multy.sql. Битрикс отдалённо похожие страшилища генерит. Ещё немного подкрутите — будет как там. Универсальность — это конечно здорово. Но, как всегда, с производительностью будет так себе.

Пробема в том, что для крупных сайтов нужна производительность, а для мелких не нужна гибкость. Я до сих пор не понял, на кого рассчитана эта система. Как баловство — очень здорово, логично и мне всё нравится. Но на практике я бы с таким столкнуться не хотел.

[boolive]

Про производительность я не спорю, но и не молчу, на форуме всё сказано и предложны варианты оптимизации. На счёт гибкости – не на пустом месте всё создаётся, не было бы этого и подобных проектов, если бы вы (подавляющее большинство) и я не желали бы гибкости в условиях сегодняшнего рынка :)…

При всём этом мною вопросы производительности не забываются.