Мне нужно было сделать небольшое доказательство концепции для компании, в которой я работаю. Я просмотрел как Spring MVC 3, так и Tapestry 5.
Для тех, кто не использовал Tapestry, у него есть действительно хорошие соглашения для потока пользовательского интерфейса, например. кнопки нажаты или по ссылкам. Также хорошо, что все в вашем классе Page является ThreadLocal, поэтому вам не нужно беспокоиться о параллелизме на этом уровне.
С другой стороны, мне не нравилась поддержка Tapestry Ajax. В нем есть свои теги для выполнения ajax-операций (зоны и т.д.), но это сложно сделать
$.ajax({
url: "tapestry_page",
success: function(result) {
// do something with json result
}
});
из-за типов возвращаемых данных, принимаемых гобеленом. Вы сказали, что ваш проект будет насыщен javascript, и это может означать много ajax. Только по этой причине я бы выбрал Spring. Вы можете просто аннотировать свои методы @Controller с помощью @ResponseBody, и все, что вы вернете, будет записано непосредственно в тело ответа. Это полезно для прямого написания json или xml (который в большинстве случаев генерируется автоматически с помощью Jackson или JAXB).
С Spring самым большим плюсом является то, что это очень зрелый проект, и поэтому все, что вам нужно, возможно, кому-то понадобилось до вас, и решение доступно (не то, чтобы то же самое не относится к Tapestry, но для Spring существует больше документации).
Несколько недостатков Spring: он очень тесно связан с сервлетами, doGet и doPost, и такие вещи, как обработка форм, не выполняются так согласованно, как в Жизненный цикл формы Tapestry. Если вы выполняете много синхронных операций, концепция страницы Tapestry очень хороша и, возможно, вам подойдет.
Я не уверен, что Tapestry достигла точки, когда вы можете настроить все свое приложение без xml, но Spring удалось. Это может быть преимуществом для вас.
Мои 2 цента.
person
Sotirios Delimanolis
schedule
08.03.2013
