Что лучше: разрешить Сервисам обращаться к нескольким DAO или только к другим Сервисам

Question

Я не нашел никаких вопросов, касающихся этой конкретной проблемы.Что лучше: разрешить Сервисам (или фасадам) получить доступ к нескольким DAO (классам, которые обращаются к базе данных) или только к другим Сервисам?

Другими словами, я должен ввести взаимозависимости между различными классами Сервисов илиЛучше сделать классы обслуживания полностью независимыми друг от друга, введя более одного DAO (при необходимости) для каждого класса обслуживания?

Я обнаружил, что обе стратегии будут работать, но я хочу быть последовательным и делатьприложение максимально модульное и обслуживаемое.

Answer 1

В этом есть определенное мнение, но настоящий «сервисный» метод должен быть атомарной единицей работы.Если они создают сеть взаимозависимости, вызывающую друг друга вперед и назад, очевидно, что вызовы не выполняют элементарных задач.Я не вижу ничего плохого в том, чтобы позволить "службе" использовать все необходимые ей DAO.Создав набор методов «service» -CRUD, абстрагирующих DAO, который уже является набором методов CRUD, который сам по себе, вероятно, абстрагирует абстракцию JPA, вы можете увидеть, как это может быть слишком много уровней нефункциональной абстракции.

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

(Можете ли вы сказать, что лично я считаю, что JPA устарела вся идея DAO, и мы должны просто использовать EntityManager в сервисе? :))

Answer 2

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

1. Если службе B требуется другая функциональность, уже включенная в услугу A, то она должна вызвать ее. Я пытаюсь уменьшить зависимости между службами и обычно заканчиваю тем, что определяю небольшой набор «базовых» служб, которые можно вызывать из других служб.

2. Создание метода в службе только для переноса вызова в DAO бессмысленно (на мой взгляд), и поэтому я предпочитаю, чтобы службы вызывали столько DAO, сколько им нужно. Опять же, сервис или метод со многими DAO указывают на то, что должно быть реорганизовано, или модель данных, которая нуждается в корректировке.