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

Question

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

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

1-й

UI layer 
    | 
Application layer 
    | 
Domain Layer 
    | 
Infrastructure Layer 

второй

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

Что разница между ними.

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

Благодаря

Update

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

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

Struts 2 JPA HSQLDB

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

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

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

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

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

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

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

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

благодаря

Answer 1

На мой взгляд, «Слои» представляют собой логическое разделение, без проявления топологии развертывания.

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

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

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

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

Answer 2

От Wikipedia:

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

В основном, есть 3 "части" по адресу:

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

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

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

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

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

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