PT
Окей, спасибо.
Хм, да все, что мне нужно от rest framework в кторе есть. А вот затачивать под себя его проще.
И принципиальных отличий от spring MVC я тут как-то не вижу, в отличии от советов.
Size: a a a
2020 September 28
SB
Зависит, наверное, от задачи. Если вам не нужно ходить в БД, кэши и всякие там кафки - то, наверное, ктор подойдёт. В противном случае спринг даст из коробки намного больше чем ктор.
PD
Зависит, наверное, от задачи. Если вам не нужно ходить в БД, кэши и всякие там кафки - то, наверное, ктор подойдёт. В противном случае спринг даст из коробки намного больше чем ктор.
Не надо путать всю инфраструктуру Spring (т.е. кучу разнообразных и независимых библиотек) с конкретным ktor.
Так как я бы не стал использовать Spring ни для работы с БД (это ORM, а оно почти всегда антипаттерн, особенно в виде JPA), ни для работы с кафкой (там много неописанной магии, так что нет понимания, какие гарантии сохраняются), ни для кэшей (все равно нужно смотреть в конкретное решение).
От Spring обычно нужно Core, Security и MVC.
Для микросервисов Core не очень нужно, но можно взять Kodein. Для MVC нормально работает ktor. Для security обычно тоже достаточно то, что есть в ktor.
Так как я бы не стал использовать Spring ни для работы с БД (это ORM, а оно почти всегда антипаттерн, особенно в виде JPA), ни для работы с кафкой (там много неописанной магии, так что нет понимания, какие гарантии сохраняются), ни для кэшей (все равно нужно смотреть в конкретное решение).
От Spring обычно нужно Core, Security и MVC.
Для микросервисов Core не очень нужно, но можно взять Kodein. Для MVC нормально работает ktor. Для security обычно тоже достаточно то, что есть в ktor.
GD
Не надо путать всю инфраструктуру Spring (т.е. кучу разнообразных и независимых библиотек) с конкретным ktor.
Так как я бы не стал использовать Spring ни для работы с БД (это ORM, а оно почти всегда антипаттерн, особенно в виде JPA), ни для работы с кафкой (там много неописанной магии, так что нет понимания, какие гарантии сохраняются), ни для кэшей (все равно нужно смотреть в конкретное решение).
От Spring обычно нужно Core, Security и MVC.
Для микросервисов Core не очень нужно, но можно взять Kodein. Для MVC нормально работает ktor. Для security обычно тоже достаточно то, что есть в ktor.
Так как я бы не стал использовать Spring ни для работы с БД (это ORM, а оно почти всегда антипаттерн, особенно в виде JPA), ни для работы с кафкой (там много неописанной магии, так что нет понимания, какие гарантии сохраняются), ни для кэшей (все равно нужно смотреть в конкретное решение).
От Spring обычно нужно Core, Security и MVC.
Для микросервисов Core не очень нужно, но можно взять Kodein. Для MVC нормально работает ktor. Для security обычно тоже достаточно то, что есть в ktor.
Что для работы с БД тогда на ваш взгляд использовать?
GK
Зависит, наверное, от задачи. Если вам не нужно ходить в БД, кэши и всякие там кафки - то, наверное, ктор подойдёт. В противном случае спринг даст из коробки намного больше чем ктор.
Спринга из коробки нет, потому что нет коробки. Ktor нужно сравнивать с конкретными подмножеством библиотек фреймворка Spring, причём в контексте решения конкретной задачи.
GK
Что для работы с БД тогда на ваш взгляд использовать?
Паттерн может быть антипаттерном только в определенном контексте. ORM - это паттерн.
ORM удобны, особенно с JPA. Если не предвидится экстремальных нагрузок, если не нужен "ручной" контроль запросов и/или нужно что-то быстро запилить, то почему бы и не использовать
Spring Data JPA.
В противном случае -
Spring Data JDBC.
ORM удобны, особенно с JPA. Если не предвидится экстремальных нагрузок, если не нужен "ручной" контроль запросов и/или нужно что-то быстро запилить, то почему бы и не использовать
Spring Data JPA.
В противном случае -
Spring Data JDBC.
GD
Паттерн может быть антипаттерном только в определенном контексте. ORM - это паттерн.
ORM удобны, особенно с JPA. Если не предвидится экстремальных нагрузок, если не нужен "ручной" контроль запросов и/или нужно что-то быстро запилить, то почему бы и не использовать
Spring Data JPA.
В противном случае -
Spring Data JDBC.
ORM удобны, особенно с JPA. Если не предвидится экстремальных нагрузок, если не нужен "ручной" контроль запросов и/или нужно что-то быстро запилить, то почему бы и не использовать
Spring Data JPA.
В противном случае -
Spring Data JDBC.
Смутила категоричность выше относительно ORM)
GK
Смутила категоричность выше относительно ORM)
Фил бывает радикален, как и любой из нас)
GK
Наверно в современном мире (микросервисов) уже почти не бывает просто Spring, и стоит говорить о Spring Boot на самом деле.
Даже если говорить о модульных монолитах, если аспектов (зависимостей/библиотек) Spring становится много, то это сигнал, что монолит может быть уже не очень-то и модульным.
Даже если говорить о модульных монолитах, если аспектов (зависимостей/библиотек) Spring становится много, то это сигнал, что монолит может быть уже не очень-то и модульным.
СХ
Что для работы с БД тогда на ваш взгляд использовать?
в джаве? jdbc, очевидно)
SB
в джаве? jdbc, очевидно)
зачем тогда все эти корутины и асинхроны, он же синхронный
N
Так это база должна ещё уметь.
N
Если база создаёт новый процесс на каждый конекшн и внутри него работает синхронно
N
То от корутин на клиенте толку нет
GK
зачем тогда все эти корутины и асинхроны, он же синхронный
Можно сделать асинхронную обработку на синхронной базе и jdbc.
N
Можно сделать асинхронную обработку на синхронной базе и jdbc.
Это как ? Как в базе сделать асинхронщина , если она не умеет
СХ
Nikolay
Это как ? Как в базе сделать асинхронщина , если она не умеет
не в бд, а до нее
GK
Nikolay
Это как ? Как в базе сделать асинхронщина , если она не умеет
Зачем вам асинхронность?
SB
Можно сделать асинхронную обработку на синхронной базе и jdbc.
Если цель - сделать, то, наверное можно. Если цель - улучшить какие-то характеристики приложения, то какой смысл.
GK
Если цель - сделать, то, наверное можно. Если цель - улучшить какие-то характеристики приложения, то какой смысл.
Какие именно?