Описывать архитектуру для веб-приложений Java? [закрытый]

давайте делиться Java на основе архитектуры веб-приложений!

есть много разных архитектур для веб-приложений, которые должны быть реализованы с использованием Java. Ответы на этот вопрос могут служить библиотекой различных конструкций веб-приложений с их плюсами и минусами. Хотя я понимаю, что ответы будут субъективными, давайте постараемся быть максимально объективными и мотивировать все " за " и "против", которые мы перечислили.

используйте уровень детализации предпочитаю описывать вашу архитектуру. Чтобы ваш ответ имел хоть какую-то ценность, вам придется описать основные технологии и идеи, используемые в описываемой вами архитектуре. И последнее, но не менее важное:--23-->, когда должны ли мы использовать вашу архитектуру?

я начну...

обзор архитектуры

мы используем 3-уровневую архитектуру, основанную на открытых стандартах от Sun, таких как Java EE, Java Persistence API, Servlet и Java Server Страницы.

  • настойчивость
  • бизнес
  • презентация

возможные коммуникационные потоки между слоями представлены:

Persistence <-> Business <-> Presentation

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

настойчивость

осуществляет создание, чтение, обновление и удаление ( CRUD) операций сохраняемости. В нашем случае мы используем (Java Persistence API) JPA и мы в настоящее время используем спящий режим как наш поставщик персистентности и использование его EntityManager.

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

кроме того, этот слой также сохраняет сущности JPA что такие вещи, как Account, ShoppingCart etc.

бизнес

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

этот слой делится на несколько классов и каждый из этих классов аннотируется @Stateless стать Безгосударственный Сеанс Bean (SLSB). Каждый SLSB называется менеджер и, например, менеджер может быть классом, аннотированным, как упоминалось, называется AccountManager.

когда AccountManager необходимо выполнить операции CRUD он делает соответствующие вызовы экземпляра AccountManagerPersistence, который является классом в слое настойчивость. Грубый набросок двух методов в AccountManager можно:

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

мы используем:операции с контейнером диспетчера поэтому нам не нужно делать демаркацию транзакций нашего "я". Что в основном происходит под капотом, мы инициируем транзакцию при входе в метод SLSB и фиксируем ее (или откат) непосредственно перед выходом из метод. Это пример соглашения по конфигурации, но у нас не было необходимости ни в чем, кроме требуемого по умолчанию.

вот как учебник Java EE 5 от Sun объясняет обязательный атрибут сделки для Enterprise JavaBeans (EJB):

если клиент работает в транзакция и вызывает предприятие метод bean, метод выполняется в рамках транзакции клиента. Если клиент не связанные с транзакция, контейнер запускает новая транзакция перед запуском метод.

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

презентация

наш уровень представления отвечает... презентация! Он отвечает за пользовательский интерфейс и показывает информацию пользователю, создавая HTML-страницы и получая пользовательский ввод через запросы GET и POST. В настоящее время мы используем старый сервлет ' S + Java Server Pages (JSP) сочетание.

слой вызывает методы в менеджеры бизнес-уровня для выполнения операции, запрошенные пользователем, и получение информации для отображения на веб-странице. Иногда информация, полученная от бизнес-уровня, является менее сложными типами, как Stringи intэгерс, а в другой раз сущности JPA.

плюсы и минусы с архитектурой

плюсы

  • наличие всего, что связано с определенным способом сохранения в этом слое, означает, что мы можем поменять использование JPA на что-то другое, без необходимости переписывать что-либо на бизнес-уровне.
  • нам легко поменять наш слой презентации на что-то другое, и, вероятно, мы это сделаем, если найдем что-то лучше.
  • позволить контейнеру EJB управлять границами транзакций приятно.
  • использование сервлета + JPA легко (для начала), и технологии широко используются и реализуются на многих серверах.
  • использование Java EE должно облегчить нам создайте систему высокой доступности с помощью балансировки нагрузки и не более. И то и другое мы считаем необходимым.

минусы

  • используя JPA, вы можете хранить часто используемые запросы как именованные запросы, используя @NamedQuery аннотация класса сущности JPA. Если у вас есть как можно больше, связанных с сохраняемостью в классах сохраняемости, как в нашей архитектуре, это распространит места, где вы можете найти запросы включить также объекты JPA. Будет сложнее просматривать операции сохранения и, следовательно, сложнее поддерживать.
  • у нас есть объекты JPA как часть нашего слоя персистентности. Но!--2--> и ShoppingCart, разве это не бизнес-объекты? Это делается таким образом, как вы должны коснуться этих классов и превратить их в сущности, которые JPA знает, как обращаться.
  • сущности JPA, которые также являются нашими бизнес-объектами, создаются как объекты передачи данных (DTO ' s), также известный как объекты Value (VO). Это приводит к анемичной домена модель поскольку бизнес-объекты не имеют собственной логики, кроме методов доступа. Вся логика делается нашими менеджерами на бизнес-уровне, что приводит к более процедурному стилю программирования. Это не хороший объектно-ориентированный дизайн, но может это не проблема? (В конце концов, объектная ориентация-не единственная парадигма программирования, которая принесла результаты.)
  • используя EJB и Java EE вводят немного сложности. И мы не можем использовать чисто Tomcat (добавление микроконтейнера EJB не чисто Tomcat).
  • есть много проблем с использованием сервлета + JPA. Использовать Google для получения дополнительной информации об этих проблемах.
  • поскольку транзакции закрываются при выходе из бизнес-уровня, мы не можем загружать любую информацию из сущностей JPA, которая настроена для загрузки из базы данных, когда это необходимо (используя fetch=FetchType.LAZY) от внутри слоя презентации. Это вызовет исключение. Прежде чем возвращать объект, содержащий такие поля, мы должны быть уверены, что вызываем соответствующий геттер. Другой вариант-использовать Java Persistence Query Language (JPQL) и FETCH JOIN. Однако оба эти варианта немного громоздки.
142
architecture java java-ee

10 ответов

хорошо, я сделаю (короче) один:

  • интерфейс : гобелен (3 для старых проектов, 5 для новых проектов)
  • бизнес-слой: Весна
  • Дао : Ibatis
  • База Данных: Oracle

мы используем поддержку транзакций Sping и запускаем транзакции при входе в уровень сервиса, распространяясь вниз к вызову DAO. Уровень обслуживания имеет большинство знаний модели бизнес-процессов, а DAO делают относительно простой CRUD работа.

некоторые более сложные запросы обрабатываются более сложными запросами в бэкэнде по соображениям производительности.

преимущества использования Spring в нашем случае заключается в том, что мы можем иметь зависящие от страны/языка экземпляры, которые находятся за прокси-классом Spring. На основе пользователя в сеансе при выполнении вызова используется правильная реализация страны/языка.

управление транзакциями почти прозрачно, откат на исключениях времени выполнения. Мы используем непроверенные исключения, насколько это возможно. Раньше мы делали проверенные исключения, но с введением Spring я вижу преимущества непроверенных исключений, только обработка исключений, когда вы можете. Это позволяет избежать много шаблонных "поймать / перестроить" или "бросить" вещи.

извините, это короче, чем ваш пост, надеюсь, вы найдете это интересным...

18

Идеальные Технологии Веб-Разработки На Основе Java Сегодня.

Веб-Слой :

HTML + CSS+Ajax+JQuery

RESTFul Web Controller/Action / Уровень Обработки Запросов:

Play Framework

Уровень Бизнес-Логики / Сервиса:

используйте чистый Java-код как можно дольше. Здесь можно сделать слияние веб-сервисов.

уровень преобразования данных XML/JSon:

XMLTool (Поиск В Google Код), JSoup, Google GSon, XStream, JOOX (поиск по коду Google)

Настойчивость Слой :

CRUD : JPA или SienaProject или QueryDSL / Сложные запросы: JOOQ, QueryDSL

18

вот мои 5 центов

презентация

Android, Угловой.JS и веб-клиента, OAUTHv2

API

REST, Jersey (JAX-RS), Jackson (JSON de-/сериализация), DTO-объекты (отличные от бизнес-логических моделей)

Бизнес-Логики

весна для DI и обработки событий. DDD-ish подход объектов модели. Более длительные рабочие места выгружаются с помощью SQS в рабочих модулях.

Дао

модель репозитория с Spring JDBC-шаблоны для хранения объектов. Redis (джедаи) для лидеров, используя упорядоченные списки. Memcache для хранения маркера.

база данных

MySQL, Memcached, Redis

9

то, что мы следовали в нашем проекте:

технология переднего конца

  • AngularJS
  • в HTML5
  • С помощью CSS3
  • в JavaScript
  • Bootstrap 3

API

  1. остальное
  2. ДЖЕРСИ (JAX-RS)
  3. УВЕРЕНЫ
  4. ВЕСЕННЯЯ ЗАГРУЗКА
  5. Джексон
  6. весна безопасность

Бизнес-Логики

  • ВЕСЕННИЕ ДАННЫЕ

  • весенние данные MongoDB

базы данных

  • MongoDB

сервер (для кэширования)

  • redis
7

мы все еще используем обычный стек Struts-Spring-Hibernate.

для будущих приложений мы изучаем Spring Web Flow + Spring MVC + Hibernate или Spring + Hibernate + веб-службы с гибким интерфейсом.

отличительной характеристикой нашей архитектуры является модульность. У нас есть несколько модулей, некоторые из которых начинаются с 3 до 30 таблиц в базе данных. Большинство модулей состоят из бизнес-и веб-проектов. Бизнес-проект содержит бизнес-логику и настойчивость пока web держит логику представления.
На логическом уровне существует три уровня: бизнес, настойчивость и презентация.
Зависимости:
Презентация зависит от бизнеса и настойчивости.
Настойчивость зависит от бизнеса.
Бизнес не зависит от других слоев.

большинство бизнес-проектов имеют три типа интерфейсов (примечание: не GUI, это программный интерфейс java).

  1. интерфейс, который использует презентация как клиент
  2. интерфейс, который используют другие модули, когда они являются клиентом модуля.
  3. интерфейс, который может использоваться для административных целей модуля.

часто 1 расширяет 2. Таким образом, легко заменить одну реализацию модуля на другую. Это помогает нам принять к различным клиентам и интегрировать более легко. Некоторые клиенты будут покупать только определенные модули, и нам нужно интегрировать функциональность, которую они уже имеют. С интерфейс и уровень реализации разделены, легко развернуть реализацию модуля ad-hock для этого конкретного клиента, не затрагивая зависимые модули. И Spring Framework позволяет легко вводить различные реализации.

наш бизнес-уровень основан на POJOs. Одна тенденция, которую я наблюдаю, заключается в том, что эти POJOs напоминают DTOs. Мы страдаем от анемичным домена модель. Я не совсем уверен, почему это происходит, но это может быть из-за простоты задачи домен многих наших модулей, большая часть работы является CRUD или из-за разработчиков, предпочитающих размещать логику где-то еще.

4

вот еще одна веб-архитектура, над которой я работал:

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

Уровень Представления:

  • JSP /JQuery (MVC на стороне клиента)
  • Родном Android
  • родной iPhone

  • мобильный веб (HTML5/CSS3/адаптивный дизайн)

  • регуляторы остатка весны (смогите изменить к JAX-RS)

Бизнес-Уровня:

Spring @Service (может измениться на Безгосударственный EJB)

Уровень Доступа К Данным:

Spring @Repository (может измениться на Безгосударственный EJB)

Ресурсов Уровня:

объекты гибернации(JPA) (Can изменить на любой ORM)

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

3

ИМХО, у большинства из нас есть общий знаменатель. По крайней мере, в задней части у нас есть какая-то форма контейнера IOC/DI и структура персистентности. Лично я использую для этого Guice и Mybatis. Различия заключаются в том, как мы реализуем слой view/UI/presentation. Существуют 2 основных варианта (может быть больше) .. Действие на основе (URL-адреса, сопоставленные контроллерам) и компонент на основе. В настоящее время я использую компонентный слой презентации (используя калитку). Он отлично имитирует среду рабочего стола, где я используйте компоненты и события в отличие от URL и контроллеров. В настоящее время я ищу причину, по которой я должен перейти на эту архитектуру URL-контроллера (вот как я оказался на этой странице). Почему шумиха о RESTful и безгосударственных архитектурах.

чтобы ответить на этот вопрос вкратце: я пишу веб-приложения с состоянием, используя компонентно-ориентированную структуру поверх контейнера Guice IOC и помещаю данные в реляционную базу данных с помощью Mybatis.

2

немного отличается, и я бы сказал, что здесь более модульная архитектура java. У нас есть:

  1. Весна WS / Rest / JSP передний конец
  2. Spring MVC для логики бизнес-сервиса, содержащей логику уровня презентации, а также транзакции Spring
  3. компонентный интерфейс связи обслуживания, посмотрел вверх через EJB обслуживаниями дела. EJBs устанавливают собственные границы транзакций, которые могут присоединяться к транзакциям Spring.
  4. компонент сервис реализации, снова Spring components
  5. уровень интеграции, MyBatis для интеграции баз данных, Spring WS для интеграции веб-служб, другие технологии интеграции для других служб
  6. мэйнфреймы, базы данных, другие службы на других серверах...

в дополнение к вышесказанному, у нас есть общие библиотечные модули, которые являются общим поставщиком функциональности для всех srevices.

польза различных слоев позволяет нам вполне decoupling и модульность нам нужна. Мы также можем полностью использовать силу Java EE, а также Spring. Ничто не мешает нам использовать JSF, например, для переднего плана, если это необходимо.

по сравнению с примером архитектуры OP, я думаю, что это можно описать как наличие четырех основных слоев вместо трех, хотя и с завихрением.

1

Я работал над проектами, которые используют этот жесткий шаблон менеджера. Исторически я был большим сторонником жесткой иерархии, где все укладывалось в аккуратную коробку. По мере того, как я продвигаюсь в своей карьере, я нахожу это вынужденным во многих случаях. Я считаю, что принятие более гибкого мышления в отношении дизайна приложений приводит к лучшему продукту. Что я имею в виду, создавая набор классов, которые решают проблему. Вместо того, чтобы говорить: "вы создали менеджера для этого и это?"

текущий проект, над которым я работаю, - это веб-приложение с комбинацией вызовов Spring MVC и RestEasy JSON/Ajax. На стороне сервера, встроенной в наши контроллеры, есть разумный уровень данных на основе фасада с JPA / Hibernate для прямого доступа к базе данных, некоторый доступ EJB и некоторые вызовы веб-служб на основе SOAP. Связывание всего этого вместе - это некоторый пользовательский код контроллера java, который определяет, что сериализовать как JSON и вернуться к клиенту.

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

0

компоненты Архитектура Веб-Приложений включает :

1 : браузер : взаимодействие с клиентом

        HTML
        JavaScript
        Stylesheet

2 : интернет

3 : веб-сервер

        CSS
        Image
        Pages(Java render )

4 : Сервер Приложений

        App Webapp (Java interaction)
        Others WebApps

5: Сервер Баз Данных

        Oracle, SQL, MySQL

6 : Сведения

0