К сожалению я успел проработать только первую часть руководства из шести. И мне она показалась достаточно законченной для того, чтобы показать её отдельно.
Работа с моделью, БД рассматривается в мануале в следующих главах. Дойдут руки — напишу :)
начало хорошее.
а вот дальше, когда надо изменить схему роутинга, использовать разные классы spring-овских контроллеров, добавить больше логики приложения и отображения, подключить БД…
вот тут вопросов гораздо больше )
думаю начинающим это очень поможет.
В junit 4 не надо расширять TestSuite, а тестовые методы помечаются аннотацией @Test. Eclipse с junit'ом может вас и поняли, но так поступать не принято.
Spring и Java-фреймворки вообще — для написания строгих компилируемых приложений, отсюда и столько конфигурационных файлов и лишних, на ваш взгляд, телодвижений.
А вы не знаете, сколько в среднем простых запросов (например, генерация и вывод формы) выполняет в секнуду приложение на этом фреймворке? Есть какие-то цифры?
Я вас не понимаю. Если вам здесь не важна производительность, почему бы не взять Руби, с его приятным синтаксисом?
Си использовать невыгодно, так как на нем невозможно (практически) нормально написать что-то сложнее хелловорда: автоматическое освобождение памяти, операции со строками и прочим, все приходится писать с нуля.
(Если вы хотите привести в пример например ядро Линукса, как программу сложнее хэлловрлда, учтите, что оно нахоится в ужасном состоянии, код труднопонятен, там нет даже объектов и исключений, а трудоемкость и стоимость поддержки и разработки тоже высока).
Может для криворуких и сложно что-то написать на Си, но на нем написано громадное количество приложений и не только операционных систем, но и скажем, систем для сбора и предоставления финансовой информации.
Ну я про то, что в любом подходе важно соотношение быстродействия/удобства разработки/удобства поддержки и еще массы параметров.
Написать вэбсервер для одной задачи можно на C и он будет быстрее других решений, которые заняли бы меньше времени на реализацию, обладали бы простотой поддержки и массой других преимуществ.
С другой стороны используя фрэймворки и плюшки языков (допустим Руби и Рельсы) я быстро разработаю весь функционал, но работать будет медленней чем C-шный аналог.
Единственное, почему может проще поддерживать приложение написанное на (PHP, Ruby и прочим), так это то, что на них сейчас больше программистов вот и все.
Фрэймворки и прочие плюшки написаны людьми, это я к тому, что все это можно написать и на Си, притом уже такие штуки есть.
Можете спросить зачем?
Можно даже взять, не Си, а PHP, фрэймоврков под него хоть отбавляй. Но зачем мне они? Если мне нужен только какой-то определенный функционал и я не хочу тащить огромный груз кода. Да, я потрачу немного времени на разработку, но зато для всех последующихих проектов у меня будет свой код, в котором не будет ничего лишнего.
Кода тестировали web приложение на java + spring + hibernate + tomcat + gwt
Производительность измерялась в сотнях динамических страниц(точнее запросов с динамически формируемым ответом) в секунду — точнее сказать не могу, давно это было.
Желез было 2х4 xeon 16G RAM
зы: По ощущениям того тестирования я ожидал как минимум на порядок меньше.
Спасибо, примерный порядок величины понятен. По моим наблюдениям, примерно того же порядка цифры у PHP (у меня на Intel Core 2 Duo, 2×1.8 Ггц 130 запр/сек с Апачем и примерно 400-500 без). При использовании тяжелых фреймворков, понятно, отставание было бы больше.
Ну для этого есть Grails (htttp://grails.org), который использует тот же Spring^ но конфигов минимум и пишутся они на Groovy. (В итоге даже полаконичние чем ваш пример на Питоне).
Извартная реализация этих самых событий и behaviours через __get/__call/__set (это же неэффективно, и код получается запутанный, и выглядит извратно как-то).
Для трансформации xml в html я вообще не напишу ни строчки кода. А напишу XSLT шаблон. Сущности сгенерю при помощи опять же XSLT. При этом написав XSD схему я буду всегда уверен, что мне не подсунут кривой XML.
В JSON нет такой мощи, извините.
Я, кстати, вчера выложил пример небольшого уже работающего приложения на Spring 3 и Hibernate. Если вам интересно, могу сюда ссылку дать.
Само приложение — сырое, и кое что там даже и не работает, но дает понять как двигаться дальше.
много букв из ряда «как сделать», но почти нет букв на тему «зачем это делаем и почему делаем так».
вот например, вы пишете:
«Для развертывания приложения на сервере воспользуемся ant-скриптом (для начала работы с Ant достаточно прочитать заметку о нем в Википедии). Скрипт будет содержать цели для компиляции, построения и переноса приложения.» и приводите антовый скрипт, не поясняя зачем и что вы делаете и почему именно так. Ну разве начинающий поймёт? Он скопирует, вставит и будет работать, однако не врубится в суть и смысл.
Философия другая. Если человек уже начал изучать спринг — в его интересах самому это все разбирать. Он должен хотеть. Не хочет знать что такое ант — его проблема. Не хочет разбираться зачем ему этот скрипт — его проблема. Это все мое скромное мнение.
А вот как раз таких туториалов, где все собрано step-by-step — очень мало.
Я согласен, что статься написана достаточно эскизно, опущен момент установки и Томката, и Eclipse, и плагина к Эклипсу. Согласитесь, тот, кому оно нужно, разберется с мелкими деталями, лентяя и талмуд не спасет :)
Не хочу поднимать флейм, но зачем все это? Неужели кто-то в здравом уме будет все это использовать, писать многокилометровые XML-и только ради того, чтобы прикоснуться к миру J2EE? Какая экономическая целесообразность? Ведь намного проще и быстрее (а значит и выгоднее) использовать легковесные фреймворки — тот же Grails (если уж так хочется джаву), RoR, Django и т.п.
Мне просто реально интересно. Знаю, что люди используют, но не понимаю, почему. Скажу сразу — Spring пытался использовать, но дальше того примера, который был приведен, особо и не ушел — мне мое время жалко, и я понял, что это не мое.
Согласен, J2EE тяжеловесная штуковина. Но я на этом пишу. Работа такая. А теперь вопрос: Ты начинаешь писать свой проект. Знаешь только J2EE, тебе быстрее писать на то, что ты знаешь, или с нуля начинать учить django и т.д.?
Гы, быстрее выучить django и потом быстренько сделать. Пример из жизни — мне надо было написать одно сетевое приложение. Я очень хорошо знал дотнет, и мог быстро на нем все слабать (скажем за месяц). Но я решил сделать приложение кроссплатформенным, поэтому скрипя сердце взялся за Python. В итоге я за две недели (первые 3-4 дня на изучение питона) написал это приложение. Почему? Потому что на нем писать быстрее, проще, и есть удобные и легкие в использовании библиотеки.
Думаю, аналогия понятна — лучше день потратить, а потом долететь. На J2EE ну реально все очень долго разрабатывать (если конечно, это не однотипные проекты с наработками, которые просто перекидываются из проекта в проект). Хотя саму джаву я уважаю, но веб-разработка под ней — это тихий ужас (если, конечно, не использовать легковесные фреймворки).
Вот это я и хотел услышать. Действительно, с распределенными транзакциями я не работал, и те фреймворки, которые я использую, их не поддерживают (насколько я знаю).
А вот насчет кластерных решений не понял. Точнее, я понимаю, что это звучит круто, но без уточнения непонятно о чем речь. Кластер чего? Серверов приложений? Чем обычный load balancer мешает это организовать?
Кстати, а вы не в курсе как связать GWT со спрингом? А то у нас никак не получается, столько всего попробовали, и не работает, хоть ты тресни. Может у вас есть какой-то работающий рецепт?
Спасибо за ответ.
Я, кстати, видел этот туториал. Не получилось. Почему? Потому что GWT уже давно не 1.5beta, Spring у нас уже третий стоит, соответсвенно все там не так и не работает.
Один вариант вроде как завели, но разрабатывать в нем — ужас, потому что при изминении кода идет перекомпиляция всего проекта.
Наверно будем ждать времени, когда google сделает интеграцию с maven и/или spring'ом куда более прозрачной.
Не пробовал на третьем, но по идее там все примерно так-же должно быть. Главное это контроллер/резолвер который знает на какой бин какой запрос перебрасывать. Один раз помучаться и работает до следующего major release gwt или spring :)
Да я ж и говорю, вроде как завели, и оно даже в hosted mode работает, но сделал небольшое изминение в ОДНОМ файле — жди пока проект пересоберется. Для разработки же это ну никуда не годится.
Дык для разработки нужно использовать develop mode ;)
Хостед — да, собирает, компилирует java в javascript, создает пермутации для каждого браузера…
А в девелоп-режиме клиентская часть — на лету.
Спасибо за комментарий. С мавеном и аннотациями напишу уже в следующем посте.
PS И насколько я понял, ещё не все разработчики бросились переходить на мавен.
Делаем простое веб приложение на Spring Framework MVC