Веб-фреймворк

[konsoletyper]

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

Comments

[m_a_m_o_n]

Чур без обид, видно что вы проделали большую работу.

Но сразу возникает вопрос, чем ваш фреймворк лучше
того же http://www.playframework.org/.

[anton_arhipov]

я думаю не стоит вдаваться в дискусси, чем новый велосипел может быть лучше других 20
лучше тем - что свой! :)

[konsoletyper]

Знаю про него достаточно давно. Ну что значит "лучше"? Он другой и всё. Если всмотреться, то разница станет очевидной. Уж какой в конкретном случае лучше - зависит от. По моему личному мнению, play как-то несколько больше "прибит гвоздями" что ли...

[m_a_m_o_n]

О да, они взяли от PHP сколько смогли.

[asuilin]

Меня всегда умиляли разработчики, создающие ООП-обертки над SQL. Вместо общепринятого языка с простым, логичным и понятным синтакисиом, идеально приспособленного для работы с реляционными данными, получаем вот такое:

qb.with(note)
.filter(note.title().like("%" + filterText + "%"))
.sortDesc(note.creationDate())
.take(limit)
.fetch(note.id(), note.title(), note.creationDate())

А когда начнутся projections и aggregations, так вообще туши свет. Причем, чтобы написать такую Java конструкцию для более-менее сложного зпроса, все равно надо держать в голове SQL, в который она оттранслируется: реляционную сущность работы с данными не скрыть даже за толстым слоем ООП.

Зачем?

Зачем в шаблонизаторе надо было заново изобретать свой JSTL и JSP-EL, тоже не совсем понятно.

То есть начинать описание библиотеки следовало с:
1. Чем это лучше Spring/Guice (кстати в современном Spring можно обойтись вообще без XML)
2. Чем это лучше JSP/Freemarker/Haml/etc

[lexicore]

Не в курсе, что там товарищ написал, но ООП-обёртка над SQL/HQL/JPQL и т.п. имеет смысл тогда, когда запрос не статический, а создаётся динамически/программно.
Есть, например, что-то типа такого, запрос надо в итоге в SQL перевести. Без нормальной объектной модели для целевого языка запросов сделать это не так просто.
Ну и далее - существующий запрос дополнительно отфильтровать (и ещё и ещё), саггрегировать, наложить пивотирование и т.п. В общем, хорошее API для программного конструирования запросов - инструмент мощный и полезный. Но, естественно, это микроскоп не для каждого гвоздя.

Я такое API написал для HQL в своё время. Оказалось очень полезным.

[m_a_m_o_n]

Я для генерации запросов использую маленький вспомогательный
класс который оборачивает StringBuilder и ArrayList.

sql.join("WHERE id=?", id);
-->
sb.append(queryPart);
params.add(id);

Думаю понятно зачем это нужно и как я это дальше использую.

+ Немножко юнит тестирования.

А всякие конструкции типа .where() и .like()...
не вижу в них бонуса.
1. Запросы бывают очень сложные и метамодель которая
генерирует такие запросы в их понимании не помогает.
2. Просто SQL код достаточно понятен на мой взгляд, тут я соглашаюсь с комментом выше.

[lexicore]

Конкатенация строк работает для сравнительно простых случаев. Например, когда структура запроса более-менее статична, там да, там хоть обаппендайся.
В сценариях более старшего школьного возраста без чего-то типа Criteria API уже не обойдёшься. Ну или обойдёшься с громоздким кодом.
Пример я выше приводил - преобразование запросов из одного языка запросов в другой.

[anton_arhipov]

в Spring вроде бы уже давно на каждый чих XML писать не надо. Ну это дело вкуса конечно же :)

[m_a_m_o_n]

А мне нравятся конфиги на XML.
1. Не нужно городить городушки из классов что бы
использовать одну и ту же логику в разных местах
с разными настройками.
2. Вся структура проекта видна в одном месте,
а не размазана по classpath.

[anton_arhipov]

Согласен. Просто это было приведено как аргумент
В данном случае - поддерживаю XML.

Хотя если "договориться" в команде, и придерживаться договорённых правил разбрасывания аннотаций по коду, можно неплохо смешивать XML с аннотациями - будет тоже хорошо.

[lexicore]

Кстати, да. Я тоже за XML-конфиги, причем без autowiring. Оно так очевидней.

[slonopotamus]

Язык разметки, напоминающий вики-разметку.

Шаблон представляет из собой обычный XML-файл.

???

[konsoletyper]

А что непонятно?

[w4x4]

а чо все так apache click не любят вспоминать?

[magicprinc]

+1

Apache Click (внутри Velocity/Freemarker).

Думаю его главная проблема, что он при своей замечательной функциональности - простой.

Васе Пупкину же надо уебаться до кровавых соплей, километры xml кода для JSF написать. Выучить сотню аннотаций для SpringMVC.
Познать границы неизведанного с play.

[w4x4]

// его главная проблема ... - простой.

почему проблема? ) не оч. понял

[magicprinc]

Пацаны уважать не будут.

Совсем дело когда у тебя на 3 гига xml портянка - сразу ясно, серьезный разработчик