Предоставить возможность совместного использования архитектур веб-приложений на основе Java!
Существует множество различных архитектур для веб-приложений, которые должны быть реализованы с использованием Java. Ответы на этот вопрос могут служить библиотекой различных проектов веб-приложений с их плюсами и минусами. Хотя я понимаю, что ответы будут субъективными, постарайтесь быть настолько объективными, насколько мы можем, и мотивируем плюсы и минусы, которые мы перечисляем.
Используйте уровень детализации, который вы предпочитаете для описания вашей архитектуры. Чтобы ваш ответ имел какую-либо ценность, вам, по крайней мере, нужно будет описать основные технологии и идеи, используемые в описываемой вами архитектуре. И последнее, но не менее важное: когда мы должны использовать вашу архитектуру?
Я начну...
Обзор архитектуры
Мы используем трехуровневую архитектуру, основанную на открытых стандартах от Sun, таких как Java EE, Java Persistence API, Servlet и Java Server Pages.
- Постоянство
- Бизнес
- Презентация
Возможные коммуникационные потоки между слоями представлены следующим образом:
Persistence <-> Business <-> Presentation
Что означает, например, что уровень представления никогда не вызывает или не выполняет операции сохранения, он всегда делает это через бизнес-уровень. Эта архитектура предназначена для удовлетворения потребностей веб-приложения высокой доступности.
Постоянство
Выполняет операции сохранения, чтения, обновления и удаления (CRUD). В нашем случае мы используем (Java Persistence API) JPA, и в настоящее время мы используем Hibernate в качестве нашего провайдера persistence и его EntityManager.
Этот уровень разделен на несколько классов, где каждый класс имеет дело с определенным типом сущностей (т.е. объекты, связанные с корзиной покупок, могут обрабатываться одним классом персистентности) и используются одним и только одним менеджером.
Кроме того, этот слой также сохраняет объекты JPA, которые являются такими, как Account, ShoppingCart и т.д.
Бизнес
Вся эта логика, привязанная к функциональности веб-приложения, находится в этом слое. Эта функция может инициировать денежный перевод для клиента, который хочет оплатить продукт онлайн, используя свою кредитную карту. Это может быть также создание нового пользователя, удаление пользователя или вычисление исхода битвы в сетевой игре.
Этот слой делится на несколько классов, и каждый из этих классов аннотируется с помощью @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 s, метод выполняет в рамках транзакции клиентов. Если клиент не связан с транзакции, контейнер запускает новой транзакции перед запуском Метод.
Обязательный атрибут - это неявный атрибут транзакции для всех предприятия bean, работающие с транзакция, управляемая контейнером демаркация. Обычно вы не устанавливаете Обязательный атрибут, если вам не нужно переопределить другую транзакцию атрибут. Поскольку транзакция атрибуты являются декларативными, вы можете легко изменить их позже.
Презентация
Наш уровень представления отвечает за... презентацию! Он отвечает за пользовательский интерфейс и показывает информацию пользователю, создавая HTML-страницы и получая пользовательский ввод через запросы GET и POST. В настоящее время мы используем старый Servlet + Страницы сервера Java (JSP).
Слой вызывает методы в менеджерах бизнес-уровня для выполнения операций, запрошенных пользователем, и для получения информации, отображаемой на веб-странице. Иногда информация, полученная из бизнес-уровня, является менее сложными типами как String и int egers, а в других случаях сущности JPA.
Плюсы и минусы с архитектурой
Pros
- Наличие всего, что связано с определенным способом выполнения настойчивости в этом слое, означает, что мы можем перейти от использования JPA к чему-то другому, не переписывая что-либо на бизнес-уровне.
- Нам легко сменить наш слой презентации на что-то еще, и, вероятно, мы сможем, если найдем что-то лучшее.
- Позволяет контейнеру EJB управлять границами транзакций.
- Использование Servlet + JPA очень просто (для начала), и технологии широко используются и реализуются на множестве серверов.
- Использование Java EE должно облегчить нам создание системы высокой доступности с балансировкой нагрузки и завершается с ошибкой. Оба они чувствуют, что мы должны иметь.
Против
- Используя JPA, вы можете хранить часто используемые запросы как именованные запросы, используя аннотацию
@NamedQueryв классе сущности JPA. Если вы, насколько это возможно, связаны с сохранением в классах персистентности, как и в нашей архитектуре, это будет распространять места, где вы можете найти запросы, чтобы включить объекты JPA. Будет сложнее просмотреть операции сохранения и, следовательно, будет труднее поддерживать. - У нас есть сущности JPA как часть нашего слоя сохранения. Но
AccountиShoppingCart, разве они не бизнес-объекты? Это делается так, как вам приходится прикасаться к этим классам и превращать их в объекты, которые JPA знает, как обращаться. - Объекты JPA, которые также являются нашими бизнес-объектами, создаются как объекты передачи данных (DTO), также называемые объектами Value (VO-х). Это приводит к JPQL) и сделать
FETCH JOIN. Однако оба этих параметра немного громоздки.