Шаблон шлюза связан с предоставлением единой точки доступа для системы или подсистемы. Шаблон DAO - это особый тип шлюза - он обеспечивает единственное средство получения данных определенного типа из хранилища данных.
Я отвечу на вопросы напрямую, здесь и подробно остановлюсь на ответах ниже.
1. Какие предположения верны.
Патент DAO занимается тем, что скрывает детали извлечения сущностей и запросов над сущностями. Возврат набора записей, который напрямую связан с механизмом персистентности, как правило, не очень хорошая идея, поскольку он нарушает абстракцию. Сохраняя независимость от хранилища DAO, тестирование становится намного проще - тогда можно смоделировать интерфейс DAO, используя, например, простую реализацию в памяти, основанную на тестовых данных, хранящихся в коллекциях.
2. Каким должен быть тип возврата для DAO (т.е. getContact () - для одной записи)
Тип возвращаемого значения должен быть Contact bean. Когда вы добавляете атрибуты к контакту, нужно изменить только класс Contact - интерфейс DAO остается прежним.
3. Должен ли getContacts () (для нескольких записей) быть даже в DAO, если да, то каков его тип с повторным вызовом?
Я ставлю методы запросов вместе с другими методами DAO - на самом деле я не вижу различий. Несколько контактов могут быть возвращены в виде списка или соответствующей коллекции Contact бобов.
Дискуссия о возврате объектов или просто необходимых значений - это вопрос расширяемого дизайна и производительности. Выбор по умолчанию должен возвращать Beans. Большинство средств отображения ORM и даже уровни доступа JDBC делают создание объектов относительно легким (современные JVM могут создавать новый объект менее чем за 10 инструкций ЦП), и это, безусловно, лучший выбор дизайна, который будет легко развиваться.
Возможен возврат необъектных результатов, таких как список CustomerID, но его следует принимать при наличии явных доказательств того, что это необходимо. Производительность, как правило, является мотивирующим фактором, поэтому проект должен быть подкреплен данными профилирования. В противном случае это может принести в жертву хороший дизайн в пользу преждевременной оптимизации. Расширение дизайна, который возвращает необъектные данные, может быть затруднено - скажем, вы хотите вернуть идентификатор клиента и дату последнего заказа. Если вы возвращаете данные в виде строк и примитивных типов, то форма возвращаемого типа изменится, что обычно требует изменения методов в интерфейсе и реализации DAO и всех клиентов, которые их используют. С bean-компонентом связанные данные могут быть получены без изменения формы данных - при условии, что связанные данные доступны, начиная с уже возвращаемого bean-компонента.
Бобы не должны быть полностью заселены. ORM-преобразователи имеют тенденцию лениво извлекать связанные объекты и коллекции, поэтому вы берете удар производительности за то, что именно вы получаете.
Подводя итог, можно предположить, что, хотя существует множество методов, возвращающих результаты bean и non-bean, я бы отклонился от результатов non-bean, если для этого нет веских причин. И делайте это с осознанием проблем обслуживания, которые это может вызвать.