Гугление по текущему положению вещей дает примерно такой общий ответ: "Spring был замечательной и действительно полезной вещью те многие годы, пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все преимущества перед ней".
Это действительно так, или адепты Java EE приукрашивают ситуацию? Вот возьмем некий абстрактный новый проект на современной платформе: Wildfly 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. Имеет ли смысл задумываться о том, тыкать ли туда Spring?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Гугление по текущему положению вещей дает примерно такой общий ответ: "Spring был замечательной и действительно полезной вещью те многие годы, пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все преимущества перед ней".
Так пишут апологеты JEE. JEE много лет имеет одну никак не решаемую проблему. Она называется Corner Cases. Если чего-то нет в спецификации, то это реализуется только средствами вендора либо вовсе через задницу. Эта проблема никак не решена и решена не будет по причине того чем JEE является.
А>Это действительно так, или адепты Java EE приукрашивают ситуацию?
Приукрашивают. На JEE стало, действительно, проще писать, но геморроя меньше не стало. Где-то сопли из старых спецификаций тянутся. Где-то просто что-то не продумали.
В результате если у тебя WebLogic, то ты счастлив и всеми руками за JEE. А если у тебя GlassFish, то ты каждую неделю пасешься в его багтрекере.
А>Вот возьмем некий абстрактный новый проект на современной платформе: Wildfly 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. Имеет ли смысл задумываться о том, тыкать ли туда Spring?
На вкус и цвет. Всё очень сильно зависит от того какой именно набор технологий нужен. На чем фронт-энд? Нужна ли MQ? Достаточно ли JPA API?
B>В результате если у тебя WebLogic, то ты счастлив и всеми руками за JEE. А если у тебя GlassFish, то ты каждую неделю пасешься в его багтрекере.
А если Wildfly?
B>Всё очень сильно зависит от того какой именно набор технологий нужен
Бэк-энд: фоновые задачи типа "возьми файл с FTP, вытащи из него интересную инфу, запиши ее в БД, в случае неудачи сообщи по мейлу админу". Реализация собственно интерфейсов передачи данных (FTP, мейл и т.д.) в данном контексте неинтересна, она у нас для 99% случаев уже есть и работает. Вопрос стоит о том, чтобы все это красиво запихать в новую платформу.
Фронт-энд: администрирование этих самых фоновых задач.
B>На чем фронт-энд?
Его нет еще совсем, равно как и ограничений по технологиям для его реализации.
B>Нужна ли MQ?
WebSphere MQ? Нет. Или очереди вообще? JMS нужна, да.
B>Достаточно ли JPA API?
Да.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А> Имеет ли смысл задумываться о том, тыкать ли туда Spring?
Я думаю однозначно тебе никто не ответит никогда. Может тебе spring подойдет, может dropwizard может еще чего. Я бы при выборе проекты на гитхабе поискал, сделал бы форк на поиграться, потом уже думал.
On 22.09.2015 09:45, "Аноним931" wrote: > Гугление по текущему положению вещей дает примерно такой общий ответ: > "Spring был замечательной и действительно полезной вещью те многие годы, > пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким > говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все > преимущества перед ней". > Это действительно так, или адепты Java EE приукрашивают ситуацию? Вот > возьмем некий абстрактный новый проект на современной платформе: Wildfly > 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. > Имеет ли смысл задумываться о том, тыкать ли туда Spring?
Туда — нет. За последние годы сделали несколько крупных проектов на базе
JEE6/7 (бэк, сервера приложений — jboss/wildfly и weblogic) + AngularJS
(фронт), процесс очень понравился. Сейчас занимаемся в числе прочего
доработкой одного проекта, сделанного на Spring+Tomcat, он нравится
определённо меньше.
С другой стороны приложения, не требующие контейнера, (микросервисы)
пишем с использованием спринга (spring boot), тоже представляется
достаточно удобным.
Здравствуйте, hrensgory, Вы писали:
h> Туда — нет. За последние годы сделали несколько крупных проектов на базе h> JEE6/7 (бэк, сервера приложений — jboss/wildfly и weblogic) + AngularJS h> (фронт), процесс очень понравился. Сейчас занимаемся в числе прочего h> доработкой одного проекта, сделанного на Spring+Tomcat, он нравится h> определённо меньше.
A>Я думаю однозначно тебе никто не ответит никогда. Может тебе spring подойдет, может dropwizard может еще чего. Я бы при выборе проекты на гитхабе поискал, сделал бы форк на поиграться, потом уже думал.
Ну я, собственно, и не ожидаю (пока) однозначного ответа "да"/"нет". Хотелось бы для начала услышать мнения именно к моей "обобщенной" постановке вопроса. Т.е. хотелось бы начинать опыты сразу на тех технологиях/библиотеках/фреймворках, которые мне с некой относительно высокой вероятностью подойдут, и не тратить время на остальные.
Понимаю — все это пока звучит очень пространно. Но конкретнее в данный момент просто не получается
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Ну я, собственно, и не ожидаю (пока) однозначного ответа "да"/"нет". Хотелось бы для начала услышать мнения именно к моей "обобщенной" постановке вопроса. Т.е. хотелось бы начинать опыты сразу на тех технологиях/библиотеках/фреймворках, которые мне с некой относительно высокой вероятностью подойдут, и не тратить время на остальные. А>Понимаю — все это пока звучит очень пространно. Но конкретнее в данный момент просто не получается
Смотри. Есть JEE спецификация. Она состоит из требований и API для разных решений — UI, работа с БД, очередь сообщений, бизнес-логика и т.п.
Когда ты берешь JEE сервер, то ты получаешь и пачку фреймверков под каждое из этих решений. Opensource сервера это вообще сборная солянка из opensource решений с API в форме JEE.
Spring же позволяет выбрать каждый фреймверк независимо, по желанию, и интегрироваться с ним.
On 22.09.2015 11:56, Dziman wrote: > h> Туда — нет. За последние годы сделали несколько крупных проектов на базе > h> JEE6/7 (бэк, сервера приложений — jboss/wildfly и weblogic) + AngularJS > h> (фронт), процесс очень понравился. Сейчас занимаемся в числе прочего > h> доработкой одного проекта, сделанного на Spring+Tomcat, он нравится > h> определённо меньше. > > А чем конкретно меньше нравится?
Тем, что всё то же самое, что есть в JEE, там пишется другими
аннотациями — reinvent a wheel несколько печалит, непонятно почему бы не
реализовать просто соответствующие части jee спек.
Ну и там Spring MVC использован, по сравнению с веб-клиентом на ангуляре
сложнее отделять фронтэнд. Хотя это непосредственно к спрингу отношения
не имеет.
H>Ну и там Spring MVC использован, по сравнению с веб-клиентом на ангуляре сложнее отделять фронтэнд
О! Вот этот пункт мне лично очень интересен. В гугле находятся сотни восторженных отзывов именно о связке Spring MVC + AngularJS ("...не могу себе теперь представить делать проект как-то по-другому"). А ты противопоставляешь их. Можешь пояснить? А то я ни в первом, ни во втором ни бум-бум.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
On 22.09.2015 14:48, "Аноним931" wrote: > H>Ну и там Spring MVC использован, по сравнению с веб-клиентом на > ангуляре сложнее отделять фронтэнд > > О! Вот этот пункт мне лично очень интересен. В гугле находятся сотни > восторженных отзывов именно о связке Spring MVC + AngularJS > (/"...не могу себе теперь представить делать проект как-то > по-другому"/). А ты противопоставляешь их. Можешь пояснить? А то я ни в > первом, ни во втором ни бум-бум.
AngularJS — это чистый JS, ему всё равно что на сервере. В наших JEE
проектах на сервере REST на JAX-RS (благо он теперь тоже часть JEE),
весь хтмл рендерится ангуляром на клиенте. Это даёт возможность полного
отделения фронта от бэка, так что у чистых фронтэндщиков, которые
работают с внешним видом приложения и клиентским кодом, на машинах
вообще нет никаких томкатов/веблоджиков, им не надо ничего
собирать/деплоить и т.п. что положительно сказывается на
производительности труда и финансовых результатах проектов.
В том проекте, о котором я упоминал, используется более классический
Spring MVC (то есть там есть V, рендерящийся на сервере). Наверняка
можно и Spring MVC сделать чисто REST сервером, хотят тут встаёт вопрос
— а зачем же тогда V в этом MVC?
Здравствуйте, hrensgory, Вы писали:
H>В том проекте, о котором я упоминал, используется более классический H>Spring MVC (то есть там есть V, рендерящийся на сервере). Наверняка H>можно и Spring MVC сделать чисто REST сервером, хотят тут встаёт вопрос
Когда делали Spring REST обнаружили, что он выходит сплошной копипастой Spring MVC. Поэтому просто добавили всё недостающее в Spring MVC
Здравствуйте, Аноним931, Вы писали:
А>Гугление по текущему положению вещей дает примерно такой общий ответ: "Spring был замечательной и действительно полезной вещью те многие годы, пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все преимущества перед ней". А>Это действительно так, или адепты Java EE приукрашивают ситуацию? Вот возьмем некий абстрактный новый проект на современной платформе: Wildfly 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. Имеет ли смысл задумываться о том, тыкать ли туда Spring?
Application server — ад. Он в принципе никому не нужен, кроме тех кто его продает. Самая большая проблема — появляются зависимости, которые само приложение никак не определяет. Соответственно, если надо их поменять, то не получится, надо что-то сделать не так как как в аппликейшн сервере — тоже проблема. Потом, если честно, то приложение, на мой взгляд, смотрится довольно забавно, когда требует установки какого-то монстра всего-лишь для того, чтобы общаться с базой и показывать html.
Спринг же более гибкая альтернатива, дает выбор что тянуть а что нет. Не нравится то, что в спринге — вытягивай с наружи. Я бы ваще guice взял, все остальное — библиотеками.
On 22.09.2015 16:19, Blazkowicz wrote:
> H>В том проекте, о котором я упоминал, используется более классический > H>Spring MVC (то есть там есть V, рендерящийся на сервере). Наверняка > H>можно и Spring MVC сделать чисто REST сервером, хотят тут встаёт вопрос > Когда делали Spring REST обнаружили, что он выходит сплошной копипастой > Spring MVC. Поэтому просто добавили всё недостающее в Spring MVC
Вполне по-моему логично, непонятно только чего бы заодно не реализовать
спеку JAX-RS здесь.
Кстати внутри того же веблоджика дофига перепакованного спринга.
Здравствуйте, hrensgory, Вы писали:
H>Вполне по-моему логично, непонятно только чего бы заодно не реализовать H>спеку JAX-RS здесь.
Заодно
In January 2011 the JCP formed the JSR 339 expert group to work on JAX-RS 2.0.[2] The main targets are (among others) a common client API and support for Hypermedia following the HATEOAS-principle of REST. In May 2013, it reached the Final Release stage
H>Кстати внутри того же веблоджика дофига перепакованного спринга.
До покупки Ораклом у них и в мануале было написано — используйте Spring где только можете.
SK>Application server — ад. Он в принципе никому не нужен, кроме тех кто его продает.
Я могу себе представить, что AS являются очень даже подходящим решением для больших фирм, у которых на серверах крутится много разного софта от многих разных поставщиков. Т.е. некий дополнительный слой стандартизации рантайма.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Я могу себе представить, что AS являются очень даже подходящим решением для больших фирм, у которых на серверах крутится много разного софта от многих разных поставщиков. Т.е. некий дополнительный слой стандартизации рантайма.
Работая уже много лет в тех "больших фирмах" наблюдаю всё меньше и меньше монстров типа Web Sphere/Web Logic (уже несколько лет не встречал, если честно), большие приложения стараются сделать в виде сервисов используя Tomcat и Jetty. Спринг используется везде где только можно.
Здравствуйте, Antei, Вы писали:
A>Здравствуйте, Аноним931, Вы писали:
А>>Я могу себе представить, что AS являются очень даже подходящим решением для больших фирм, у которых на серверах крутится много разного софта от многих разных поставщиков. Т.е. некий дополнительный слой стандартизации рантайма.
A>Работая уже много лет в тех "больших фирмах" наблюдаю всё меньше и меньше монстров типа Web Sphere/Web Logic (уже несколько лет не встречал, если честно), большие приложения стараются сделать в виде сервисов используя Tomcat и Jetty. Спринг используется везде где только можно.
Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
Здравствуйте, Transformerrr, Вы писали:
T>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
Получается, что принцип JEE — спецификация отдельно, вендор отдельно — не работает? Т.е. с WebLogic просто так не уйти на JBoss? Не холивара ради, практический интерес.
On 24.09.2015 15:08, dya-victor wrote:
> Получается, что принцип JEE — спецификация отдельно, вендор отдельно — > не работает? Т.е. с WebLogic просто так не уйти на JBoss? Не холивара > ради, практический интерес.
Мы переходили в рамках JEE6 с WL на JBoss (в обоих направлениях).
Были мелкие нюансы с конфигурацией jax-rs, в остальном — всё работает.
