Подтвердить что ты не робот

Должны ли отношения между Службой и DAO быть от одного до одного или от одного до многих?

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

UPDATE:

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