GWT и Spring MVC, действительно ли это стоит того?
Это поместит значения опции #myselectbox в хороший чистый массив для Вас:
// First, get the elements into a list
var domelts = $('#myselectbox option');
// Next, translate that into an array of just the values
var values = $.map(domelts, function(elt, i) { return $(elt).val();});
4 ответа
Я не вижу в целом хорошего смысла в использовании Spring MVC или другой корпоративной библиотеки Java MVC (например, Struts) вместе со слоем, который, как вы сказали, предлагает только бизнес-логику (и, следовательно,
Но сам Spring - это больше, чем просто уровень веб-инфраструктуры (MVC), использующий внедрение зависимостей или функции AOP, ORM API или язык сценариев Groovy (который отлично работает с Spring) может быть огромным преимуществом для любого приложения.
Spring - это гораздо больше, чем просто MVC.
Даже когда вы создаете пользовательский интерфейс с помощью GWT, вам все равно нужна какая-то внутренняя логика. Такие вещи, как базы данных, транзакции, безопасность, интеграция дополнительных сервисов (электронная почта? SOAP?) И т. Д.
Для этой Spring или любой другой серверной технологии Java может быть хорошим решением.
Как сказал daff, Spring приносит DI + AOP + транзакции + много всего ... Полезно иметь управление этими материалами на стороне сервера с помощью Spring.
Кроме того, библиотека gwtrpc-spring предлагает очень удобный способ объявления POJOS как служб rpc с аннотацией @Service. Он избегает объявления каждого сервлета rpc в файле web.xml, поскольку сканирование классов с помощью @Service выполняется автоматически.
GWT - это просто набор инструментов, а не фреймворк. Если Spring поможет вашему разработчику, просто используйте его.
Я предпочитаю GWT + GIN на стороне клиента и Guice на стороне сервера. Но Spring с таким же успехом можно использовать для обеспечения устойчивости, транзакций и организации вашей бизнес-логики на стороне сервера.