Предложения по разработке крупномасштабного веб-приложения Java с нуля

Question

Я собираюсь приступить к разработке крупномасштабной системы и пытаюсь понять, в каком направлении двигаться дальше.Я уже делал множество веб-приложений на Java и имею большой опыт работы с контейнерами сервлетов и GWT и некоторый опыт работы со Spring.Проблема в том, что большинство моих веб-приложений были собраны вместе просто для подтверждения концепции, и я борюсь с тем, какой набор фреймворков использовать.Мне нужно иметь как браузерное приложение, так и веб-сервис, предназначенный для поддержки доступа с мобильных устройств (на данный момент Android и iPhone).В идеале я хотел бы спроектировать эту систему таким образом, чтобы в конечном итоге я не переписывал все свои сервлеты для каждого клиента (браузера и телефона), хотя я не против иметь там небольшие проверки для правильного форматированияdata.

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

Итак, где я сейчас нахожусь, планирую использовать GWT для разработки интерфейса на основе браузера, но я борюсь с тем, как повторно использовать этот код для представленияинтерфейс (скорее всего, xml) для мобильных устройств.Я думаю, что использование GWT RPC сделало бы относительно легким выполнение всего AJAX в браузере, но могло бы затруднить создание xml для мобильных телефонов.Кроме того, мне нравится идея использовать что-то вроде Hibernate для устойчивости и Spring Security для защиты всего этого.Опять же, я не уверен, насколько хорошо они будут сотрудничать с GWT (я думаю, что Hibernate должен быть в порядке ...)

Очевидно, что здесь гораздо больше, чем я представил здесь, но я пыталсячтобы дать вам 5-минутный обзор.Я немного озадачен, и мне было интересно, есть ли у кого-нибудь в сообществе опыт, начиная с этого места.Имеет ли смысл то, что я пытаюсь сделать?Это реально?Я не сомневаюсь, что смогу заставить все эти фреймворки говорить на одном языке, мне просто интересно, стоит ли мне тратить время на борьбу с ними.Кроме того, мне не хватает фреймворка, который был бы действительно полезен?

Заранее спасибо и извините за относительно широкий вопрос ...

Крис

Answer 1

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

Мой 1. совет - сохранить любой код, который напрямую зависит от любой среды, как можно более «глупым».Если вы можете, рассмотрите такой код более или менее одноразовым (с точки зрения реализации, контракты API, предоставляемые клиентам, конечно, должны быть стабильными).

Сосредоточьтесь на том, что делает ваше приложение уникальным, и постарайтесь сделать его независимым от GWT.и т. д. шаблон фасада *1006* - это то, что я могу порекомендовать - держать логику для конкретного приложения позади и выставлять ее, подключая к ней слой представления, хорошо нам помогло.Если ваш бэкэнд зависит от сторонней инфраструктуры (через веб-сервисы и т. Д.), Отделите эти зависимости от вашего кода с помощью шаблона адаптера .

Я провел большую часть своего рабочего времени в течениепоследние 5 лет на создание чего-то, что во многом соответствует тому, что вы описали.Сегодня это скорее среда приложения, чем приложение - у него есть несколько различных интерфейсов браузера (WAP / стандартное веб-приложение + приложение ajax / Facebook), интерфейс для двухстороннего использования SMS и интерфейс REST / XML для толстых мобильных клиентов - BREW, iPhone, Android и Blackberry.

Когда речь заходит о фреймворках, для настойчивости мы использовали Hibernate.Все различные части кода связаны с Spring.Интерфейсы браузера были перенесены из Struts (1.x) в Wicket.Интерфейсы для SMS и мобильных клиентов построены поверх Restlet.

Использование нескольких различных структур уровня представления (таких как Wicket и Restlet в нашем случае) не было проблемой, если этот код остается скудным ибизнес-правила не допускаются (насколько это возможно).Ничто не говорит о том, что ваш интерфейс браузера должен быть упакован в ту же WAR, что и интерфейс вашего мобильного клиента - с помощью Spring вы можете легко подключить несколько веб-приложений с одним фасадом.Это было полезно для нас, особенно потому, что несколько разработчиков работали над хорошо изолированными частями приложения.

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