| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Groovy & Grails > Что выбрать? |
| Автор: oson 6.10.2011, 09:35 |
| Граждане! Помогите определиться с фреймворком для приложения. Это веб сайт, в котором есть выставленная в интернет для общего обозрения часть - собственно магазин. А внутри много разных людей обрабатывает эти заказыб имея свою роль, видя свои шаги в процессах и принимая определенные решения, кликая на какой-нить Next и процесс ушел к другой роли и уже другой человек его вилит - и тд и тп. То есть по сути workflow - но с интерфейсом в интернете, где покупатели точно также учавствуют вв этом workflow и имеют свои шаги и интерфейсы. Хотел использовать Seam - но народ говорит, что монолитный, тяжеловесный и ошибки кидает невразумительные периодически - и хотят съезжать с него. Посоветовали "Grails или SpringMVC как наиболее современные и качественные". Посмотрел что такое Grails - что-то из семейства Spring. Подскажите пожалуйста, какую роль в таком проекте может занять Grails, есть ли ему вообще место в такого плана проекте, и как он связан с другими продуктами Spring - то есть надо использовать и другие Springi типа SpringMVC и тп? |
| Автор: Stolzen 6.10.2011, 09:47 |
Gails сделан на основе Spring MVC. В нем можно подключать модули, коих большое количество, уверен, что и для ecommerce их немало. И еще один плюс - это язык Groovy, на котором он написан. После него java такой многословный и много чего в нем не хватает. И Groovy для java программистов дается очень легко, можно сразу садиться и писать. |
| Автор: oson 6.10.2011, 15:08 |
| Не совсем понял. Так это уже не Java? А если я захочу потом на view уровне подключить GWT например - то уже не получится? То есть буду жестко привязан уже к Grails, к тому что предлагает именно он и не смогу даже при необходимости SpringMVC подключить? |
| Автор: Stolzen 6.10.2011, 15:22 |
| Нет, не джава, JVM-based язык. Сам лично GWT не подключал, но http://grails.org/plugin/gwt, что можно. А вообще я пытался на груви писать для GWT, правда только серверную часть - вполне сносно. |
| Автор: oson 6.10.2011, 18:38 |
| То есть на базе Spring сделали новый язык? |
| Автор: emmanuil 7.10.2011, 14:52 |
| Нет, не на базе. http://ru.wikipedia.org/wiki/Groovy Это самостоятельный язык с динамической типизацией. А grails просто написан на нем. Мне понравился grails. http://grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.5 Web Flow |
| Автор: emmanuil 11.10.2011, 09:55 |
| Не надо так категорично. Альтернатива это ведь не замена. |
| Автор: oson 15.10.2011, 20:44 | ||
То есть вот стоит задача - сделать этот веб магазин (интерфейс, корзина и тп) + рабочие потоки внутри (роль менеджера по закупкам, менеджера по отправке и тп). Делал бы я ее классическим способом например JSF + Hibernate. Написал бы jsf странички, managed beans с логикой, DAO с вызовами в Hibernate и тд. А в случае с Groove-Grails я все то же самое генерирую значительно быстрее, потому что в принципе все эти классы стандартные. То есть у меня все то,что я написал бы руками на JSF+Hibernate, будет внутри обертки Grails, и никаких ограничений в реализации бизнес логики я испытывать не буду из-за того, что пишу не все руками с нуля, а использую в обертке Grails. Правильно я понял? А view уровень легко подключается на Vaadin. |
| Автор: emmanuil 15.10.2011, 20:59 |
| JSF - компонентно-ориентированный фреймворк. Либо страница, либо сервер будет хранить состояние. Это нужно учитывать, если будет много посетителей. Grails - action based. На счет скорости. В жсф есть много готовых компонентов для интерфейса. Бизнес логику нужно писать и там и там. Просто в грэйлс есть GORM, он кое-что сделает за тебя. На мой взгляд жсф больше подходит для корпоративных приложений, админок и т.п. |
| Автор: oson 15.10.2011, 21:21 |
| А можно чуть объяснить - что значит Grails - action based? |
| Автор: emmanuil 15.10.2011, 21:29 |
| Это значит request based. Не хранит состояние. Разницу можно найти в интернете. Для публичного сайта, по моему мнению, больше подходит grails или spring, чем jsf. |
| Автор: oson 15.10.2011, 22:08 |
| Там что нет такого scope как session, где можно сохранить состояние пользователя? А как же тогда интернет магазин с добавлением новых товаров в корзину будет работать? Получается это невозможно на Grails? |
| Автор: Vasay 16.10.2011, 03:53 | ||
Да я бы вообще сказал, что JSF не пригоден для публичных сайтов. Vaadin, кстати, то же. Потому, если и реализовывать на нем View, то только в админке. Но как показала практика - сделать с его помощью удобную (с точки зрения юзабилити) админку гораздо сложнее, чем средствами Grails. Про scope ответил в соседней теме. |
| Автор: emmanuil 16.10.2011, 07:08 |
Дабы не разжигать споров, высказался как можно деликатнее. |
| Автор: oson 16.10.2011, 12:43 |
| Классно! Только начал рассматривать Vaadin - как раз maven dependencies качает. А почему на Vaadin нельзя view часть сайта сделать? И чем Grails его заменяет? Я так определился уже сделать уровень view на Vaadin (это ж вроде более юзабельный интерфейс-обертка GWT), а движок либо на Grails либо на Spring - Hibernate, если Grails сильно много накладывает ограничений и, честно говоря, пока что я не понял какие преимущества он дает, кроме готовых Dao типа getNameById. А разбираться с его ограничениями по структуре и другими нюансами (типа для каждого запроса своя страничка почему-то вроде delete.jsp) может занять немало времени. Если преимуществ особых нет, то собственно зачем. Никто так и не назвал реальные преимущества Grails. Может просто дело вкуса тогда. |
| Автор: Vasay 16.10.2011, 14:12 | ||
oson
Потому что у Vaadin как и у других основанных на JS UI есть следующие проблемы: - несоответствие контента URL, как следствие: -- сайт не индексируется поисковыми системами -- пользователь не может сохранить страницу в закладки, или передать ссылку на страницу по почте или icq - непривычное для пользователя поведения JS ссылок и навигации (например, неадекватная реакция на нажатие средней кнопки мышки (открыть в новом окне), неадекватное поведение кнопки "назад" браузера ) |
| Автор: oson 16.10.2011, 14:45 | ||||
Кнопку назад лучше вообще заблокировать в проектах WorkFlow - потому что view должен отвечать состоянию системы. Но я так понял тут вообще существует проблема (у всех основанных на JS UI) несоответствия "состояния движка" и "отображения"? То есть для управления рабочими процессами она по большому счету не подходит? Что собственно взамен предлагает Grails? Есть у него что-то с rich interface? Или классические страницы только? |
| Автор: Vasay 16.10.2011, 15:48 | ||
oson
Пользователи Вам за это спасибо не скажут. К тому же, судя по описанию в Вашем первом посте, у вас WorkFlow не в том понимание которое применяется к фреймворкам (т.е. не последовательность экранов у одного пользователя). У Вас некий бизнес процесс (с передачей состояния между пользователями) который, полюбому, программировать руками. п.с. так мы все-таки говорим о публичном сайте (интернет магазине) или о его админке с неким бизнес процессом? |
| Автор: oson 16.10.2011, 16:11 | ||
Публичный сайт, где покупатели тоже имеют роль в общем процессе. После того как покупатель сделал заказ (выполнил те шаги, которые можно делать в его роли), что-то меняется в состоянии для других ролей, которые начинают видеть это заказ - менеджеры всякие - и потом шаг за шагом обрабатывают его. То есть и публичный сайт и админка - но в основе лежит именно управление рабочими потоками. То есть роль Покупатель сделал заказ и роль менеджер A увидел его, затем роль менеджер A выполнил 3 шага и перестал видеть этот заказ - зато видит роль менеджер B и делает свои шаги. |