Как должен быть реализован уровень DAO?Одна таблица DAO или несколько таблиц DAO?

Question

Я реализую модуль согласно многоуровневой архитектуре.Он будет иметь уровень представления, уровень обслуживания, бизнес-уровень и уровень DAO.Согласно многоуровневой архитектуре, коммуникационный поток должен быть сверху вниз.Точно так же зависимость должна быть сверху вниз, то есть уровень представления - использует -> уровень обслуживания - использует -> бизнес уровень - использует -> уровень DAO.т. е. бизнес-уровень не должен зависеть от уровня обслуживания, а также.

Вопрос 1:

Какими должны быть входные данные для каждого уровня?Поскольку сервисный уровень вызывается из уровня представления, должен ли сервисный уровень принимать бин UI в качестве входных данных?или Service Bean в качестве входных данных?То же самое для бизнес-уровней и уровней DAO.

Вопрос 2:

Должен ли уровень DAO быть для каждой таблицы или он может обрабатывать несколько таблиц (все принадлежат одному модулю)?Данные моего модуля хранятся в нескольких таблицах.Поскольку все эти таблицы принадлежат одному модулю, я думаю, что имеет смысл иметь один уровень DAO, который абстрагирует хранение данных из верхних уровней в несколько таблиц.Кроме того, если необходимо подключить различные реализации уровня DAO (хранилище базы данных, хранилище SVN и т. Д.), Имеет смысл подключить одну реализацию (которая обрабатывает все данные).Кроме того, DAO для нескольких таблиц будет эффективен с точки зрения извлечения данных (достаточно одного запроса на соединение)

Вопрос 3:

Если рассматривается проект DAO для нескольких таблиц, то входные данные дляУровень DAO будет бизнес-бином.На уровне DAO лежит ответственность за преобразование бизнес-компонента в несколько компонентов DB, ​​каждый из которых представляет таблицу и обрабатывает постоянство.Но это не будет соответствовать многоуровневой архитектуре, где говорится, что уровни должны быть изолированы, и любой уровень не должен зависеть от его верхнего уровня.В этом случае входные данные для уровня DAO - это бизнес-компонент (не компонент DB), а преобразование из бизнес-компонента в компоненты DB и наоборот является обязанностью уровня DAO, что означает, что он знает, как преобразовать бизнес-компонент в компонент DB.и наоборот.

Может кто-нибудь прояснить вышесказанное?Каким должен быть правильный способ реализации такого модуля?Является ли текущая реализация в соответствии с руководящими принципами?Правильное объяснение очень поможет.Спасибо!

Текущая реализация, которая у меня есть,

• Уровень представления: преобразует компонент UI в компонент службы и передает его на уровень службы.

• Сервисный уровень: преобразует сервисный компонент в бизнес-компонент и передает его на бизнес-уровень.Также организует звонки между различными зависимыми службами.Обрабатывает границу транзакции.Возвращает компонент EJB на уровень представления.

• Бизнес-уровень: передает компонент EJB на уровень DAO.Возвращает служебный компонент на уровень обслуживания

• Уровень DAO: преобразует бизнес-компонент в компоненты DB и наоборот.Возвращает бизнес-бин на бизнес-уровень.

Answer 1

В этом ответе я буду использовать пример сайта социальной сети.

1. Ваш пользовательский интерфейс должен зависеть от вашего сервиса, но только в одном направлении.Представьте себе случай, когда у вас есть несколько постов в пользовательском интерфейсе, и вы намереваетесь реализовать функцию «Мне нравится».Интуитивно понятно, что когда пользователь нажимает кнопку «Нравится» для публикации, должна быть создана запись в соответствующей таблице, которая затем отображается в пользовательском интерфейсе.Итак, вам нужна реализованная функция Like, которая в пользовательском интерфейсе означает, что у вас есть обработчик POST-запроса, который вызывает соответствующий метод на уровне сервиса, передавая идентификатор пользователя и идентификатор сообщения.Уровень обслуживания должен быть полностью независим от пользовательского интерфейса и должен обрабатывать только проверку сеанса и вызывать соответствующий метод на бизнес-уровне.Ваш бизнес-уровень должен, в свою очередь, обрабатывать логику ваших действий и обеспечивать вызов ваших методов на уровне DAO, поэтому в базе данных создается запись Like и, возможно, могут произойти некоторые другие вещи, которые могут вам понадобиться.Когда все методы DAO, которые будут вызваны, успешно выполнены (если нет, то ошибка должна быть должным образом обработана), бизнес-уровень должен реагировать на уровень обслуживания, который, в свою очередь, должен отправлять электронные письма пользователям, которые будут уведомленыи ответьте на пользовательский интерфейс.

2. Остерегайтесь дракона, называемого «преждевременная оптимизация».У вас должен быть один слой DAO, потому что он значительно упростит вашу жизнь.Если позже у вас возникнут проблемы с производительностью, вам придется их решить.Однако, если у вас возникнут проблемы с производительностью, весьма вероятно, что это будет вызвано чем-то другим.Слой DAO означает, что у вас есть слой, на котором представлен ваш DAO.

3. См. Пункт 2.