О правильном использовании DAO

Question

Зарезервирован ли DAO только для базовых операций CRUD, или он также может содержать некоторую сложную логику поиска?

Представьте себе два класса сущностей, Книгу и Автор, и отношения многих ко многим между ними. На этом этапе одного DAO может быть более чем достаточно, поскольку основные операции CRUD для обоих объектов одинаковы.

Однако, когда приложение становится более сложным, появляются новые требования, например: 1. найти первую книгу для данного автора 2. найти книги, которые автор написал в течение определенного периода времени 3. найти книги по определенной теме, которые написал данный автор 4. .... и т. Д.

Куда все это должно идти? Должен ли я создать отдельный класс DAO для каждого объекта и поместить их туда? Они вообще относятся к слою DAO?

У меня есть эта дилемма: куда должны идти следующие методы: findBooks (Автор, автор) findBooks (издатель издатель) оба в BookDAO, или один в AuthorDAO, другой PublisherDAO?

Или, может быть, мне следует подумать о совершенно новой абстракции, которая находится поверх DAO и оставляет их для базовых операций CRUD - например, SearchService, в котором перечислены все возможные поиски?

Answer 1

Зарезервирован ли DAO только для основных операций CRUD

Нет. Не стесняйтесь помещать всю логику доступа к данным в DAO.

Не путайте DAO с DAL с:

Answer 2

Куда все это должно идти?Должен ли я создать отдельный класс DAO для каждого объекта и поместить их туда?Они вообще относятся к слою DAO?

см. Ниже.

У меня есть эта дилемма: куда должны идти следующие методы: findBooks (Автор-автор) findBooks (Издатель-издатель) и в BookDAO, или один в AuthorDAO, другой PublisherDAO

Это зависит, и я думаю, что это не вопрос архитектуры корпоративного программного обеспечения, а OOD.Поскольку ваша логика усложняется, вы должны помнить об увеличении связности и уменьшении связи между программными компонентами и, соответственно, извлекать новый класс (Extact Class из каталога рефакторинга http://martinfowler.com/refactoring/catalog/extractClass.html) с этими методами, которые считаются принадлежащимитот же бизнес-контекст, как AuthorDAO для всех методов о функциональности Author и Books для всех вызовов Books, чтобы сделать ваш код более читабельным, многоразовым, тестируемым, поддерживаемым, ...

Или, может быть, яследует подумать о совершенно новой абстракции, которая находится поверх DAO и оставляет их для базовых операций CRUD - например, SearchService, который перечисляет все возможные поиски?

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

Answer 3

Куда все это пойдет?Должен ли я создать отдельный класс DAO для каждого объекта и поместить их туда?Они вообще относятся к слою DAO?

Определенно работа и вызов DAO (уровень).То, что у вас есть, не имеет значения.Конкретный метод должен идти к DAO, к которой он принадлежит.

Или, может быть, мне следует подумать о совершенно новой абстракции, которая находится поверх DAO и оставляет их для основных операций CRUD - например, aSearchService, в котором перечислены все возможные поиски?

Две вещи здесь.

1. Похоже, вы используете Hibernate или какой-либо инструмент ORM здесь.Следовательно, у вас есть подходящие объекты, которым я верю.И вы можете использовать эти объекты в слое DAO вместо Map или List или Primitives без каких-либо проблем.В любом случае, не отклоняясь от уровня DAO, вы все равно можете иметь уровень DAO здесь.И проверяйте бизнес-правила так, как вам хочется.
2. Выглядит. Вы имеете в виду шаблон AbstractDAO (поищите / google для того же самого), опять же Hibernate и Spring предоставляют такие вещи.Spring также предоставляет инструмент SearchService (на самом деле, классы) для этого.