Программирование, т. 7

Ну теперь осталось только письма поверстать таблицами и жизнь удалась 

      ты не поверишь, я этим тоже сегодня занимался 

вся правда о джаве 

 

вся правда о джаве 

если ты джавист - не смотри

 

 

 

 

jetBrains уже и до дотеров добрались...

 

 

 

 

не понял че ты хочешь

есть sql как строка.

есть с параметрами (см апишку jdbc).

ну вот я делаю так примерно - есть метод, в котором описан 1 запрос

String query = "SELECT t.* from kek t WHERE t.hui in(?)";

 

потом эту кверю кидаю через jdbc в БД и получаю resultset

видел, что челики создают xml файл и описывают все запросы там, для каждого запроса свой нейминг/id, чтобы вызывать напрямую из кода
 

спринги хуинги не варик, ибо поздно перепиливать все под это дело/дорого
вот и спрашиваю, а как так сказать "правильнее" делать? всяких запросов в БД у меня штук 20-30

      ты не поверишь, я этим тоже сегодня занимался

Так, а в чем рофл? Это и есть самая надежная верстка по сей день 

 

 

 

 

руки бы отрубал всем этим SPA

ф5 нажал и всё, пизда в 99% случаев

 

 

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

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

что за поток сознания?

при чем тут вообще спа к тому, что ты жмешь ф5 и у тебя что-то пропадает?

 

потому что 90% "ща мы сделаем SPA"

херачат себе весь сайт на одном урле, грузя в страницу аяксом вообще всё, безо всяких возможностей перехода вперед назад

 

и самое главное, непонятно зачем они себе вообще эти спа делают

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

 

что ты несешь вообще. 

 

Пытается натянуть проблему лоу-скилл прогеров, которые "забывают" наличие состояний у приложения, на парадигму SPA

 

ну так то любой хттп стейтлес.

но вообще роутинг никто не запрещает юзать,

Так, а в чем рофл? Это и есть самая надежная верстка по сей день 

Я первый раз верстал письмо. У меня в outlook 2010 почти нихуя из стилей не работало (

 

не понял че ты хочешь

есть sql как строка.

есть с параметрами (см апишку jdbc).

ну вот я делаю так примерно - есть метод, в котором описан 1 запрос

String query = "SELECT t.* from kek t WHERE t.hui in(?)";

 

потом эту кверю кидаю через jdbc в БД и получаю resultset

видел, что челики создают xml файл и описывают все запросы там, для каждого запроса свой нейминг/id, чтобы вызывать напрямую из кода

 

спринги хуинги не варик, ибо поздно перепиливать все под это дело/дорого

вот и спрашиваю, а как так сказать "правильнее" делать? всяких запросов в БД у меня штук 20-30

 

мое имхо: если тебе 1 раз написать их и 100 лет не трогать - то пиши в джаве строками, можно либо в интерфейсе константами либо в енумах, либо в любой другой статике. и будешь их брать типа

String sql = SqlQueries.AllKeksByHui;

(или в апперкейсе более типично для джавы, можешь по наименованию свой конвеншн придумать, как тебе очевиднее)

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

кстати спринг ты можешь использовать где захочешь. не обязательно 100% приложения на спринге делать. можешь хоть 1 объект в контекст запихнуть а потом в каком-то месте его достать.

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

да и вообще для набора строк которым просто нужно постоянство+имя не нужен спринг.

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

а можно спросить. ты на джаве сколько прогаешь и что (ну на каких условиях)

Изменено 24 апреля 2017 пользователем Just.Doit

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

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

а можно спросить. ты на джаве сколько прогаешь и что (ну на каких условиях)

так себе автоматизатор с 8 месяцами

ну у меня и так обращения к БД в виде статичных запросов, без изменения параметров и в виде параметризованных запросов, где параметры берутся из параметров, которые прилетают в джава метод в рантайме из под нескольких тредов, а также процедуры и прочая sql хуета лежат в одном классе DataBaseNameQueries.class, офк можно например разделить на два класса - статик запросы и параметризованные запросы

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

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

я не пишу сами запросы, вьюхи, процедуры - мне их дают готовыми. вопрос в том, как правильно организовать работу с запросами из под джавы (в плане где хранить - в стринге или нет например), без юзания фреймворков типа спринга
Изменено 24 апреля 2017 пользователем choojoykin

кант мой союзник по хранимкам 

 

 

 

 

 

руки бы отрубал всем этим SPA

ф5 нажал и всё, пизда в 99% случаев

 

 

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

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

что за поток сознания?

при чем тут вообще спа к тому, что ты жмешь ф5 и у тебя что-то пропадает?

 

потому что 90% "ща мы сделаем SPA"

херачат себе весь сайт на одном урле, грузя в страницу аяксом вообще всё, безо всяких возможностей перехода вперед назад

 

и самое главное, непонятно зачем они себе вообще эти спа делают

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

 

что ты несешь вообще. 

 

Пытается натянуть проблему лоу-скилл прогеров, которые "забывают" наличие состояний у приложения, на парадигму SPA

 

ну так то любой хттп стейтлес.

но вообще роутинг никто не запрещает юзать,

 

По-этому, на плечах прогера на фронте остаётся задача по восстановлению состояния по нажатию на f5. При MPA это было нативно, за счёт отдачи контекта сервером целиком, при SPA у тебя по сути всё асинхронно и если ты не поддержишь нормально восстановление состояний. будешь бесконечно получать пустые страницы или "забытые" фильтра и сортировки.

Разве можно сделать такое дерьмо чтобы состояния не восстанавливались?

Разве можно сделать такое дерьмо чтобы состояния не восстанавливались?

я так не делал, но как бы самый тупой способ, который на поверхности лежит - JSON.stringify(state). Ложим в sessionStorage, при F5 проверяем стораж и восстанавливаем, если есть что

да понятно что всё это сделать можно. можно через юрл. зависит от стета и желаемого поведения при различных перезагрузках и альтернативных сценариях 

суть в том что макаки когда делают СПА об этом не думают

Изменено 25 апреля 2017 пользователем Just.Doit

Макаки когда что угодно делают не думают.  Не стоит на них  и их поделки равнятся

проблема в том, что макак 95%