Предложения для разработки крупномасштабного веб-приложения Java с нуля
Я собираюсь начать разрабатывать крупномасштабную систему, и я борюсь с который направление продолжиться. Я сделал много веб-приложений Java прежде, и у меня есть много опыта с контейнерами сервлета и GWT и некоторого опыта с Spring. Проблемой является большинство моих веб-приложений, были брошены вместе только, чтобы быть подтверждением концепции и с чем я борюсь, что набор платформ использовать. У меня должны быть и приложение на базе браузера, а также веб-сервис, разработанный к доступу к поддержке от мобильных устройств (Android и iPhone на данный момент). Идеально, я хотел бы разработать эту систему таким способом, которым я не заканчиваю тем, что переписал все свои сервлеты для каждого клиента (браузер и телефон), хотя я не возражаю иметь некоторые маленькие проверки там для надлежащего форматирования данных.
Кроме того, хотя я - единственный разработчик теперь, который будет не обязательно иметь место в будущем, и я хотел бы разработать что-то, что масштабируется хорошо и относительно трафика и относительно числа разработчиков (не просто кошмар для поддержания).
Таким образом, где я, теперь планирование использования GWT для разработки интерфейса на базе браузера, но я борюсь с тем, как снова использовать тот код с представить интерфейс (наиболее вероятный xml) для мобильных устройств. Используя RPC GWT, я думаю, сделал бы относительно легким сделать весь Ajax в браузере, но мог бы сделать генерацию xml для мобильных телефонов трудной. Кроме того, мне нравится идея использовать что-то, любят, в спящем режиме для персистентности и безопасности Spring для обеспечения всего этого. Снова, я не уверен, как хорошо они будут сотрудничать с GWT (я думаю, в спящем режиме, должен быть прекрасным...),
Существует, очевидно, намного больше к этому, чем я представил здесь, но я попытался дать Вам 5-минутный обзор. Я немного озадачен и задавался вопросом, был ли у кого-либо в сообществе опыт при запуске с этого места. Что я пытаюсь сделать, имеют смысл? Действительно ли это реалистично? Я не сомневаюсь, что могу заставить все эти платформы говорить на том же языке, я просто задаюсь вопросом, стоит ли это моего времени для борьбы с ними. Кроме того, я пропускаю платформу, которая была бы действительно выгодна?
Заранее спасибо и жаль об относительно широком вопросе...
Chris
1 ответ
Здесь я буду довольно конкретен, поскольку у меня есть некоторый смежный опыт. Не все из того, что я напишу, будет применимо, но я надеюсь, что кое-что будет применимо.
Моим 1. советом будет держать любой код, который напрямую зависит от какого-либо фреймворка, настолько "глупым", насколько это возможно. Если можете, считайте такой код более или менее одноразовым (с точки зрения реализации, контракты API, открытые клиентам, должны быть стабильными, конечно).
Сосредоточьтесь на том, что делает ваше приложение уникальным, и постарайтесь сделать это независимым от GWT и т.д. Я могу порекомендовать паттерн фасада - хранение специфической для приложения логики за одним и раскрытие ее путем подключения к ней презентационного слоя сослужило нам хорошую службу. Если ваша внутренняя часть зависит от инфраструктуры третьих сторон (через веб-сервисы и т.д.), отделите эти зависимости от вашего кода с помощью паттерна адаптер.
За последние 5 лет я потратил большую часть своего рабочего времени на создание чего-то, что во многом соответствует тому, что вы описали. Сегодня это скорее фреймворк, чем приложение - он имеет несколько различных браузерных интерфейсов (WAP/стандартный веб+ajax/Facebook app), интерфейс для двустороннего использования SMS, и REST/XML интерфейс для толстых мобильных клиентов - BREW, iPhone, Android и Blackberry.
Если говорить о фреймворках, то для персистентности мы использовали Hibernate. Все различные части кода связаны вместе с Spring. Интерфейсы браузера были перенесены с Struts (1.x) на Wicket. Интерфейсы SMS и мобильных клиентов построены на базе Restlet.
Использование нескольких различных фреймворков презентационного слоя (таких как Wicket и Restlet в нашем случае) не является проблемой, пока код остается компактным и в него не включаются бизнес-правила (насколько это возможно). Ничто не говорит о том, что интерфейс браузера должен быть упакован в тот же WAR, что и интерфейс мобильного клиента - с Spring вы можете легко соединить несколько веб-приложений с одним и тем же фасадом. Это было полезно для нас, особенно в том, что позволило нескольким разработчикам работать над хорошо изолированными частями приложения.
На мой взгляд, попытка добиться максимального повторного использования кода на презентационном уровне принесла больше вреда, чем пользы. Это всегда была самая изменчивая часть нашего приложения, выходящая за рамки того, что мы могли ожидать.