Многоуровневая архитектура в Java EE

Question

У меня есть вопрос, который я так и не смог решить:

Учитывая эти две архитектуры

1-й

UI layer
    |
Application layer
    |
Domain Layer
    |
Infrastructure Layer

2-й

Client Tiers
    |
Presentation Tiers
    |
Business Tiers
    |
Integration Tiers
    |
Resources Tiers

В чем разница между ними.

Где сущностные бины лежат в этой архитектуре.Если у меня есть бизнес-уровень с объектом, который реализует бизнес-логику, зачем мне добавлять поведение в бинах сущностей.Я где-то читал, что использование модели предметной модели без поведения - это нехорошо.

Спасибо

Обновление

Это фактически проект (обучение), что мне нужно сделать, чтобы получить MS в распределенных системах.

Это на самом деле технологии, которые я использую

Struts 2 JPA HSQLDB

Так что, если я хорошо понимаю

Мое приложение состоит из

Уровень клиента (веб-браузер) Уровень представления (структуры 2) Бизнес-уровень (POJO + JPA) Уровень интеграции (с DAO гибернации) Уровень ресурсов (HSQLDB)

Но так как уровень представления, бизнеса и интеграции реализован на одном сервере (tomact), у меня есть только трехуровневая архитектура.Я прав?

Что касается поведения в моих объектах JPA, обычно это то, что я обычно делал: иметь дао для каждой сущности JPA.Иметь компонент (например, EJB), который будет управлять требуемой бизнес-логикой.Поэтому я никогда не определяю поведение объектов JPA.

Скажем, например, что я хотел сделать запрос на покупку.У меня был бы CatalogueManager, который помог бы мне взаимодействовать с предметами, поставщиками.У меня также был бы EmployeeManager, который помог бы мне взаимодействовать с сотрудниками.И, наконец, PurchaseRequestManager, который будет использовать два предыдущих бизнес-объекта для создания PurchaseRequest.

Теперь вы говорите мне о том, чтобы поместить методы, которые есть у меня в PurchaseManager, в сущность JPA PurchaseRequest и сделать то же самое.чтобы методы в EmployeeManager => поместили их в сущность JPA сотрудника.

Но что произойдет, если мой объект сотрудника также будет использоваться для отдела кадров, мне также нужно было бы поместить туда другие методы.Для большого приложения у меня было бы много методов в сущности JPA сотрудника.Разве это не будет контрпродуктивно?

спасибо

Answer 1

По моему мнению, "Слои" - это логическое разделение, без каких-либо последствий для топологии развертывания.

"Уровни" относятся к физическому развертыванию.Например, логика уровня пользовательского интерфейса может быть полностью реализована в толстом клиенте, развернута на уровне клиента на рабочем столе и не иметь отдельного уровня представления или может быть приложением на основе браузера Web 2.0, при этом уровень пользовательского интерфейса будет распределен между клиентом пользовательского интерфейса Javascript вуровень браузера и представления на сервере.

Теперь на бинах Entitiy.Во-первых, Entity Bean в EJB 3 заменены на JPA - мы аннотируем объекты, чтобы контролировать их постоянство.

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

Мне кажется разумным, что логикакасается поведения, скажем, Клиента, должно быть в классе Клиента.Такое поведение может быть довольно тривиальным, например, некоторые виды проверки и суммирования (например, общая стоимость заказа), но это логика домена и может быть разумно в этих объектах домена.Таким образом, у наших объектов JPA есть две роли: реализация доменной логики, а также управление постоянством с помощью их аннотаций.Архитектурный статус этих аннотаций интересен, они фактически являются «связующим звеном» между доменом и инфраструктурой.

Answer 2

Из Википедия :

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

По сути, есть 3 "части" для адреса:

1. Клиент - это место, где происходит презентация, и где существует программирование на стороне клиента(Javascript) для динамического взаимодействия с вашим приложением.

2. Бизнес - это то место, где существует вся ваша бизнес-логика.Алгоритмы, доменные модели, «мясо» вашего приложения.EJB живут здесь, если вы их используете.

3. Данные - обычно ваша база данных, к которой вы получаете доступ из бизнес-уровня.

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

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

Стремитесь к простоте, а не к чрезмерному использованию «архитектуры», «шаблонов проектирования», «корпоративного шаблона» или чего-либо еще, что звучит слишком корпоративно.