Должны ли отношения между Сервисом и DAO быть один к одному или один ко многим?

Question

Код, который вызвал этот вопрос, был службой в кодовой базе моей компании, которая содержала четыре различных DAO. Я не особо задумывался об этом, пока не увидел, что эта Служба стала путать с методами, которые принадлежали совершенно другой Службе. Причиной создания этих неоправданных методов внутри этого Сервиса было просто потому, что необходимые DAO были частными членами этого класса Сервиса.

Является ли это проявлением халатности разработчика, или в большинстве случаев неправильно иметь более одного DAO на класс обслуживания?

Примечание: я заметил, что разумно иметь более одного DAO на класс обслуживания, если они все содержатся в одной базе данных. Но наличие DAO из нескольких баз данных может вызвать проблемы.

Answer 1

Я не вижу ничего плохого в наличии нескольких DAO для одного класса обслуживания. Когда я впервые начал заниматься веб-разработкой много лет назад, у меня был один сервис DAO, потому что это казалось наиболее логичным и простым подходом. Затем я начал сталкиваться с проблемами, когда между DAO, обслуживающими разные службы, существуют похожие API. Таким образом, мое «незрелое» решение состояло в том, чтобы продвигать эти общие API-интерфейсы для некоторого родительского DAO, который наследуется этими DAO. Когда проект расширяется, наступает момент, когда наследование больше не имеет смысла, потому что у меня есть ситуации, когда 80% дочерних DAO нуждаются в этом API, а 20% нет, но они все еще наследуют от одного и того же родителя. DAO, потому что они используют другие похожие API. Вы видите проблему здесь? Я имею в виду, что в Java вы можете наследовать только от одного родителя, поэтому я в конечном итоге добавил API-интерфейсы, которые «могут» использоваться «большинством» DAO в родительском DAO, что в первую очередь полностью нарушает принцип наследования.

Прямо сейчас у всех моих классов DAO есть определенные обязанности / задачи. Это нормально для DAO, чтобы вызвать другой DAO (например, LoggingDAO используется большинством DAO для регистрации действий пользователя). Таким образом, вместо одного DAO, который обслуживает определенную услугу, DAO предоставляет список операций, которые могут принести пользу этой услуге. Служба будет «использовать» любые DAO, которые будут использоваться для выполнения этой задачи.

Надеюсь, это объяснение поможет.

Answer 2

Один ко многим - это хорошо, если есть смысл разбивать DAO.

Несколько причин, по которым я могу придумать, где имеет смысл разделять DAO:

• Различные базы данных. Если вы имеете дело с учетной записью и базой данных продаж, вы можете разделить DAO на SalesDAO и AccountingDAO. Это облегчит обслуживание.
• Повторное использование. У вас может быть несколько методов, которые можно повторно использовать в нескольких местах, и разделение только этих методов позволит лучше использовать повторно.

Answer 3

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

Таким образом, у них был уровень доступа, который мог вызывать несколько DAO для выполнения функций более высокого порядка, поэтому, если вы хотите выполнить заказ, может потребоваться вызов нескольких таблиц и, возможно, нескольких систем, поэтому контроллер будетвызовите метод doOrder.

Это хороший дизайн, поскольку он сохраняет хорошее чувство разделения и упрощает модульное тестирование, поскольку вы можете протестировать каждый слой.

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

Итак, когда вы разрабатываете свои уровни, посмотрите, имеет ли смысл создавать новые слои для упрощения проектов,может обнаруживать ошибки или предотвращать ошибки.

ОБНОВЛЕНИЕ:

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

Answer 4

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Сумма DAO просто зависит от базовых источников!