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

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



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



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



я начну...




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



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




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

  • бизнес

  • презентация


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



Persistence <-> Business <-> Presentation


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



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



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



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



кроме того, этот слой также сохраняет JPA entities что такие вещи, как 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

}


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



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




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



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




презентация



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



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



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



плюсы




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

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

  • сдача контейнера EJB управление транзакциями-это хорошо.

  • использование сервлета + JPA легко (для начала), и технологии широко используются и реализуются на многих серверах.

  • С помощью Java EE-это должно сделать его легче для нас, чтобы создайте систему высокой доступности с помощью балансировки нагрузки и fail over. И то и другое мы чувствуем, что должны иметь.


минусы




  • С помощью JPA вы можете хранить часто используемые запросы в виде именованных запросов с помощью @NamedQuery аннотация в классе объектов JPA. Если у вас есть как можно больше связанных с сохраняемостью в классах сохраняемости, как в нашей архитектуре, это распространит места, где вы можете найти запросы чтобы включить также объекты JPA. Будет сложнее просматривать операции сохранения и, следовательно, сложнее поддерживать.

  • у нас есть объекты JPA как часть нашего уровня персистентности. Но Account и ShoppingCart, разве это не бизнес-объекты? Это делается таким образом, как вы должны коснуться этих классов и превратить их в сущности, которые JPA знает, как обращаться.

  • объекты JPA, которые также являются нашими бизнес-объектами, создаются как объекты передачи данных (DTO ' s), также известный как объекты значения (VO). Это приводит к анемичной домена модель поскольку бизнес-объекты не имеют собственной логики, кроме методов доступа. Вся логика делается нашими менеджерами на бизнес-уровне, что приводит к более процедурному стилю программирования. Это не очень хороший объектно-ориентированный дизайн, но, может быть, это не проблема? (В конце концов, объектная ориентация-это не единственная парадигма программирования, которая дала результаты.)

  • используя EJB или Java ее сопряжено с определенными сложностями. И мы не можем использовать чисто Tomcat (добавление микроконтейнера EJB не чисто Tomcat).

  • есть много проблем с использованием сервлета + JPA. Использовать Google для получения дополнительной информации об этих проблемах.

  • поскольку транзакции закрываются при выходе из бизнес-уровня, мы не можем загружать информацию из объектов JPA, которая настроена для загрузки из базы данных, когда это необходимо (используя fetch=FetchType.LAZY) от внутри слоя презентации. Это вызовет исключение. Перед возвращением сущности, содержащей эти типы полей, мы должны обязательно вызвать соответствующий getter's. другой вариант-использовать язык запросов персистентности Java ( JPQL) и FETCH JOIN. Однако оба эти варианта немного громоздки.

784   10  

10 ответов:

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

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

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

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

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

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

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

18  
2016-10-31 22:09:31

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

Веб-Слой :

HTML + CSS+Ajax+JQuery

RESTFul Web Controller/Action / Request Processing Layer:

Play Framework

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

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

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

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

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

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

18  
2011-08-22 15:08:54

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

презентация

Android, Угловой.JS WebClient, OAUTHv2

API

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

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

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

Дао

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

база данных

MySQL, Memcached, Redis

9  
2015-08-23 19:42:44

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

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

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

API

  1. остальное
  2. ДЖЕРСИ (JAX-RS)
  3. БУДЬТЕ УВЕРЕНЫ
  4. SPRING BOOT
  5. Джексон
  6. весна безопасность

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

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

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

базы данных

  • MongoDB

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

  • Рэдис
7  
2015-09-28 14:38:40

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

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

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

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

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

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

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

4  
2009-03-17 18:37:05

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

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

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

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

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

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

Уровень Бизнес-Услуг:

Spring @Service (можно изменить на EJB без состояния)

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

Spring @Repository (можно изменить на EJB без состояния)

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

Hibernate(JPA) entities (Can изменить на любой ОРМ)

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

3  
2014-11-02 20:17:32

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

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

2  
2013-12-17 20:56:55

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

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

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

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

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

1  
2014-06-02 23:21:47

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

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

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

0  
2011-08-22 15:41:52

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

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

        HTML
        JavaScript
        Stylesheet

2 : интернет

3: Webserver

        CSS
        Image
        Pages(Java render )

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

        App Webapp (Java interaction)
        Others WebApps

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

        Oracle, SQL, MySQL

6: Data

0  
2014-09-14 19:36:05

Comments

    Ничего не найдено.
Click here to cancel reply.