Комментарии 16
Какое преимущество вы получаете, использую шаблонизатор вместо обычных insert и select?
Простота отпадает сразу, так как мне, как человеку, который работает с запросами в Java не кажется проще ваше решение.
Но, несомненно оно выглядит «красивее» танцев со строками, будь до append'ы или пачка .replace(), но последние очень просты и достаточно ясно смотрятся.
Простота отпадает сразу, так как мне, как человеку, который работает с запросами в Java не кажется проще ваше решение.
Но, несомненно оно выглядит «красивее» танцев со строками, будь до append'ы или пачка .replace(), но последние очень просты и достаточно ясно смотрятся.
Для себя я получил лаконичность.
Можно быстро собирать простые и скучные запросы в атомарные классы
(в тексте это CreateUser, GetAllBlockedUsers, UpdateUserById)
и потом передавать их в шаблонизатор, скрывая рутину.
Например в одном вызове скрыта вся рутина создания INSERT запроса:
Этот код приятно скрыл всю реализацию, оставив только саму идею, что очень ценно на уровне бизнес-логики, где не хочется отвлекаться на особенности БД.
Тоже самое делает MyBatis (скрывает сложность), но в нем бывает занудно писать в десятый раз очередной селект по id для очередного объекта БД. Поэтому появился этот простой шаблонизатор. :)
Можно быстро собирать простые и скучные запросы в атомарные классы
(в тексте это CreateUser, GetAllBlockedUsers, UpdateUserById)
и потом передавать их в шаблонизатор, скрывая рутину.
Например в одном вызове скрыта вся рутина создания INSERT запроса:
universal.update(new CreateUser(user));
Этот код приятно скрыл всю реализацию, оставив только саму идею, что очень ценно на уровне бизнес-логики, где не хочется отвлекаться на особенности БД.
Тоже самое делает MyBatis (скрывает сложность), но в нем бывает занудно писать в десятый раз очередной селект по id для очередного объекта БД. Поэтому появился этот простой шаблонизатор. :)
Советую попробовать JOOQ.
Прост, как 2 копейки, статическая типизация запросов, удобный DSL: пишешь код, как SQL-запрос.
Прост, как 2 копейки, статическая типизация запросов, удобный DSL: пишешь код, как SQL-запрос.
Кроме прочего, такой вариант проще поддерживать:
1) При изменении логики внутри запросов необходимо поправить только xml и не лезть в код (например, в больших командах будет меньше конфликтов в VCS между теми кто поправил код, исправив баг в бизнес логике, и теми кто внес правку в xml).
2) Сами xml могут быть получены извне приложения (да, такое иногда нужно).
1) При изменении логики внутри запросов необходимо поправить только xml и не лезть в код (например, в больших командах будет меньше конфликтов в VCS между теми кто поправил код, исправив баг в бизнес логике, и теми кто внес правку в xml).
2) Сами xml могут быть получены извне приложения (да, такое иногда нужно).
Ой, github.com/edolganov/live-chat-engine/search?utf8=%E2%9C%93&q=isThreadLang_EN — что это? Зачем хардкодить?
На данный момент есть только 2 языка (рус и eng).
Поэтому удобно делать такую проверку: «Если isThreadLang_EN, то показать view_en иначе view_ru».
Когда будут другие локали, то сделав поиск по вызову isThreadLang_EN будет легко заменить эту логику на более общий код (а isThreadLang_EN — выбросить). Т.о. код эволюционирует по мере необходимости.
Поэтому удобно делать такую проверку: «Если isThreadLang_EN, то показать view_en иначе view_ru».
Когда будут другие локали, то сделав поиск по вызову isThreadLang_EN будет легко заменить эту логику на более общий код (а isThreadLang_EN — выбросить). Т.о. код эволюционирует по мере необходимости.
Тот случай, когда для сборки стоит использовать Maven, при таком-то количестве зависимостей.
Да, я думаю о переходе на Maven. На первых этапах отказ от него сделал процесс разработки более быстрым и гибким.
Сейчас, когда код устоялся, можно и зависимости вынести вон из проекта.
Сейчас, когда код устоялся, можно и зависимости вынести вон из проекта.
Более быстрым и гибким? Разве ж не утомительно вручную скачивать библиотеки и все зависимости и кидать их в папку, тщательно контролируя наличие всего необходимого и нужных версий?
Мавен как раз автоматизирует задачу, сводя все труды к добавлению пары тегов, что значительно ускоряет как и первичную настройку проекта, так и последующую разработку…
Так же Мавен обеспечивает и гибкость — заменить одну библиотеку с зависимостями на конкурирующую, обновить\откатить версию — со всеми зависимостями становится намного менее хлопотно.
Я уже не говорю о размере проекта за счет выкидывания необходимых бинарников без потери возможности сборки «в один клик», о размере репозитория версионной системы, а также возможных конфликтов истории в этих самых бинарниках.
Мавен как раз автоматизирует задачу, сводя все труды к добавлению пары тегов, что значительно ускоряет как и первичную настройку проекта, так и последующую разработку…
Так же Мавен обеспечивает и гибкость — заменить одну библиотеку с зависимостями на конкурирующую, обновить\откатить версию — со всеми зависимостями становится намного менее хлопотно.
Я уже не говорю о размере проекта за счет выкидывания необходимых бинарников без потери возможности сборки «в один клик», о размере репозитория версионной системы, а также возможных конфликтов истории в этих самых бинарниках.
Подумайте еще в сторону Gradle, более продвинутая система, чем Maven.
а какова производительность?
Ant! Какой ужас!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Open source сервер онлайн-чатов на Java