Какая веб-платформа является правильной для меня? [закрытый]

Вы можете проверить Play! каркас . В настоящее время я работаю над приложением в grails, которое, похоже, работает хорошо и не особо много работал с игровой платформой, поэтому оно может сработать или не сработать для вас. Одним из недавних дополнений к игровой платформе является модуль Scala, который позволяет писать код на Scala.

Я начинаю думать, что Spring/Hibernate/Java - это единственный выход. Хотя на начальном этапе это довольно большие затраты, я знаю, что в конечном итоге они сгладятся.

Тогда, возможно, взгляните на Spring Roo (также читайте Grails vs Roo - почему SpringSource продвигает две очень похожие технологии?).

За последний год я использовал Grails в паре проектов и обнаружил, что повышение продуктивности разработки намного перевешивает недостатки, и я не нашел недостатка, с которым я бы не смог справиться.

Относительно некоторых ваших конкретных возражений:

1) реализованы ужасно. Они не кажется, может продолжаться от супер классы во время выполнения. Я пробовал это добавить базовые действия и вспомогательные методы, и это, кажется, заставляет грааль взорваться вверх.

FWIW, я никогда не чувствовал необходимости расширять контроллер из базового класса. Каждый контроллер поддерживает определенные HTTP-вызовы, которые не поддаются повторному использованию, и все необходимое повторное использование может / должно быть делегировано службе.

2) основаны на устаревшем запросе модель параметров (а не форма вспомогательные объекты, которых много приятнее).

Опять же, FWIW, это не было проблемой для меня. Grails красиво упаковывает все параметры в карту, которая мне обычно нужна. Если мне нужно больше, я создаю объект Command, что довольно просто.

3) трудно проверить. Командные объекты относятся к совершенно по-другому ... и на самом деле НАМНОГО сложнее написать тест, чем писать код контроллера.

Yep-тестирование в grails - одна из его слабых сторон. Я полностью отказался от средств тестирования Grails и просто использую Selenium для автоматизации тестирования через графический интерфейс. Не идеально, но у нас это сработало.

6) Строительные леса, которые создаются это чистая хрень. Это не обобщает вставляет и обновляет ... и на самом деле скопировать / вставить кучу кода пополам Представления: create.gsp и edit.gsp.В Сами по себе взгляды - это гигантские груды собачки делать-делать. Это дальше усугубляется тем, что он использует низкоуровневые параметры, а не объекты.

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

Интеграционные тесты в 30 раз медленнее, чем тест интеграции Spring. это отвратительный.

Некоторые имитирующие тесты так сложно пишите и не гарантируйте работу когда он развернут, я думаю, что это препятствует быстрым, тдд тестовым циклам.

Опять же, да, проверка не является сильной стороной Грааля.

Кажется, большинство вещей портят грааль пока он работает, например, добавление taglib или что-нибудь еще. Сервер проблема перезапуска вообще не решалась.

У меня не было проблем в этой области с момента выхода 1.2. Это самая чистая среда для внесения изменений во время работы, с которой я когда-либо работал. Конечно, есть некоторые вещи, требующие перезапуска (например, моды для начальной загрузки), но на большинстве этапов разработки это отлично работает.

Я начинаю думать о Spring / Hibernate / Java - единственный способ идти. Пока есть довольно большой стоимость при запуске, я знаю со временем сгладить.

Не только при запуске, но и на протяжении всего процесса разработки.Я предполагаю, что команды, с которыми я работаю, создают готовые к работе функции в 3-5 раз быстрее, чем мы могли бы использовать «традиционные» фреймворки. Это, конечно, не для всех и каждого проекта, и оно не идеально, но оно может стать огромным ускорителем, если ваш проект соответствует сильным сторонам Grails. Добавьте к этому тот факт, что вы можете в значительной степени выбирать, сколько Grails вы хотите использовать (вместо того, чтобы подключаться к слоям Spring / J2EE, если хотите), и я рассматриваю это как вариант «съесть свой пирог и съесть его тоже». Мой 2c.