контроллер стоек и сервисный уровень?

Question

В существующем приложении, над которым я работаю, классы Action будут напрямую взаимодействовать с классами DAO.

Будет ли лучше, если классы Action будут вызывать классы уровня службы (BusinessFacade), которые в свою очередь будут вызывать DAO?

Лучше ли развивать слой между классами Action и уровнем DAO?

Answer 1

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

Если вы отделитесь, вы сможете повторно использовать бизнес-логику даже в невеб-приложение.

Уровень доступа к данным предназначен в качестве уровня, на котором объекты сохраняются в абстрактном хранилище и восстанавливаются из него, и фактически, особенно в случае сохранения СУБД, могут быть хорошо реализованы ORM, поэтому частовы можете увидеть слой бизнес-логики с ORM для сохранения объектов.Я предпочитаю объединять бизнес-логику с ORM, в данном случае, а не с интерфейсной средой.

Answer 2

Целью уровня Service между вашим контроллером и уровнями DAO является инкапсуляция более сложной бизнес-логики.Это позволяет вашему контроллеру быть тупым, а ваш DAO - сосредоточиться на задаче взаимодействия с внутренним хранилищем данных (будь то база данных, плоский файл и т. Д.).

Вот пример метода уровня обслуживания с использованием SpringАннотации безопасности:

@PreAuthorize("hasRole('ROLE_ADMIN'));
public Person getPerson(long personId) {
    Person person = personDAO.getById(personId);
    if (person.getPosition().equals("MANAGER") {
       log.debug("Manager's information requested");
    }
}

Это делает две вещи, связанные с бизнес-логикой:

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

Этим действиям нет места в контроллере, и они добавляют ненужную сложность DAO.