Что было бы Вы идти для веб-приложения бэкенда: Flex, GWT, JQuery?

This might be the same as duffymo's answer, but it's worth repeating: Keep the client agnostic from the server.

In my current project, we have a JSON REST interface between client and server. This allows us to have as many different client implementations as we like. In face, the server could change completely from Java to .NET and none of the clients would care as long as the data API remained the same.

This kind of environment also can help pure-data testing. You can test both client and server (live and independantly) just by feeding JSON back and forth.

Я думаю, вы можете полностью отложить выбор, если разделите свое приложение на отдельные службы и уровень представления. Правильно настройте серверную часть, и вы сможете менять местами технологии просмотра по своему усмотрению.

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

Я лично выбрал бы Flex и Spring BlazeDS. Это сексуально.

Флекс подходит для ваших целей Я бы сказал. Используя MXML, очень легко создавать великолепные пользовательские интерфейсы с динамическими изменениями структуры и эффектами. Поскольку вы также находитесь на столь ранней стадии разработки, я бы посоветовал вам рассмотреть преимущества использования будущей версии Flex, ранее под кодовым названием Gumbo .

Gumbo предлагает множество возможностей приветствую обновления, особенно в отделе дизайна. Например, теперь намного проще создавать привлекательные пользовательские интерфейсы с динамическими оболочками, используя FXG, своего рода разметку, используемую для текстового определения графических фигур. FXG также является ключевой технологией Flash Catalyst , инструментом, используемым для преобразования дизайна в реальный код. Хотя в текущем состоянии Catalyst может быть недоступен для производственного кода качества,

It all comes down to three things:

1. What type of application are you building?
2. What is the technology skill set you're familiar with and comfortable migrating your skills to if necessary?
3. What are the technology requirements of your infrastructure?

If the application features are driving the technology, then you have to determine whether an enhanced hypertext-based application is suitable for your needs (AJAX, XHTML), or whether a more rich media technology is more suitable, such as the Flash Platform (of which Flex is a part).

No.#2 and #3 are often similar, in that they take into account your teams' existing skillset and infrastructure. If your application requirements are such that the application can be deployed with either technology, then you need to gauge what is the skillset and infrastructure support: if you're already using Java and your team is mainly experienced in AJAX, then go with that; if your team has more experience in Flash/Flex and LCDS/FMS, then use that.

But I think it's a huge misconception that a Flash Platform-based RIA can be built like an AJAX-built RIA with little architectural changes, or that you can "partition your app into separate services and a view tier... and you can swap view technologies in and out at will." That my friends is a recipe for disaster. Building a Flash Platform/Flex application means that the backend is slave to the client-side application, not the other way around, since the application intelligence will for the most part reside on the client. If you build a Flex app like an AJAX app, you're going to wind up with a completely overarchitected mess, I've seen it happen many times. The trick is knowing which parts of the Controller/Services to keep on the client, and which to keep on the server.

So in answer to your question, you have to ask yourself which is driving the development of this app -- the feature set, or the technology you know how to use? Often times people confuse the two, creating unnecessary personal bias in favour of one or the other implementation.

Я не могу согласиться с оценкой Расти Spring. Он постоянно обновляется, и в нем много возможностей.

Сказав это, я большой поклонник GWT. Я не могу сказать, что это обязательно лучше, чем любая другая технология, но мне она нравится.

Это зависит от того, сколько лошадиных сил вам нужно. Если у вас всего сотня пользователей, это не проблема, но если у вас большая база пользователей, вам нужно думать шире. GWT, вероятно, отлично работает в этих ситуациях, но большие проекты, которые я выполнял, были с другими технологиями.

Мой текущий хобби-проект - http://penwag.com . Я использую GWT для интерфейса и серверной части, а также Hibernate + MySQL для устойчивости. Все это работает под управлением tomcat, размещается на сервере rapidvps.com с (!) Гарантированным объемом оперативной памяти 128 МБ и процессором 100 МГц.

Если хотите, вы можете следовать шаблонам MVC или MVP с помощью GWT. Но, если вы используете GWT, можно также использовать подход MVP, поскольку он дает вам немного лучшее разделение проблем, чем MVC.

Есть ли предположения о том, насколько большой может быть ваша база пользователей?

Изменить:

Вот галерея приложений GWT Кстати.

Если одна из ваших основных предпосылок - хороший пользовательский интерфейс, убедитесь, что у вас есть какой-нибудь дизайнер, который вам поможет. Вы можете создать хороший пользовательский интерфейс практически на любом языке, поэтому это не структура, которая будет определять это.

Я бы рекомендовал GWT по сравнению с двумя другими, ни по какой другой причине я считаю его лучшим для меня. Ваш пробег может отличаться.

И ради всего святого, Весна? Я не хочу начинать пламенную войну, но на самом деле, зачем кому-то это делать с собой? Переключите свой проект на гораздо более стандартные технологии, такие как обычный бизнес-уровень EJB3 / JPA, легкий веб-уровень и клиент GWT, и вы буду намного счастливее. Будет меньше кода, его будет намного проще поддерживать, и вам не придется беспокоиться о какой-либо странности весенней инъекции / перехвата. Spring - это то же самое, что Struts для передней части, устаревшая, неуклюжая и старая;)