Требуется некоторое уточнение с помощью шаблонов (шлюз DAO x)

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

Один из моих коллег считает, что DAO должен вернуть объект (заполненный bean). Я думаю, что это прекрасно, когда вы возвращаете набор записей только с одной строкой, но считаете, что это слишком сложно, если вам нужно вернуть 10 строк и создать 10 отдельных объектов.

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

Мои вопросы здесь:

Какие предположения верны?
Каким должен быть тип возврата для DAO (т.е. GetContact() - для одной записи)
Должно ли getContacts() (для нескольких записей) даже находиться на DAO, если да, то что он возвращает?

Кажется, у нас какая-то путаница в отношении DAO и Gateway Patterns. Должны ли они использоваться вместе?

Заранее спасибо

Ответ 1

Шаблон шлюза связан с предоставлением единой точки доступа для системы или подсистемы. Шаблон DAO - это определенный тип шлюза - он обеспечивает единственное средство для получения определенного типа данных из хранилища данных.

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

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

2. Каким должен быть тип возврата для DAO (т.е. GetContact() - для одной записи) Тип возврата должен быть Contact bean. Когда вы добавляете атрибуты контакта, должен меняться только класс Contact - интерфейс DAO остается прежним.

3. Должен ли getContacts() (для нескольких записей) даже находиться в DAO, если да, то что он возвращает? Я ставил методы запросов наряду с другими методами DAO - я не вижу различия. Несколько контактов могут быть возвращены в виде списка или соответствующей коллекции Contact beans.

Дискуссия о возвращении объектов или только необходимых значениях является одним из расширяемого дизайна и производительности. По умолчанию должен быть возвращен beans. Большинство ORM-карт и даже слои доступа JDBC делают создание объектов относительно легкими (современные JVM могут создавать новый объект под 10 инструкциями ЦП), и это, безусловно, лучший выбор дизайна и будет легко развиваться.

Возвращаемые результаты без объекта, такие как список CustomerID, являются возможностью, но должны приниматься, когда есть четкие доказательства того, что это необходимо. Производительность обычно является мотивирующим фактором, поэтому дизайн должен быть подкреплен профилирующими доказательствами. В противном случае это, вероятно, принесет в жертву хороший дизайн в пользу преждевременной оптимизации. Расширение дизайна, возвращающего данные без объекта, может быть затруднительным - скажем, вы хотите вернуть идентификатор клиента и дату последнего заказа. Если вы возвращаете данные в виде строк и примитивных типов, форма типа возврата будет изменяться, что обычно требует изменения методов на интерфейсе DAO и реализации и всех клиентов, которые их используют. При использовании bean соответствующие данные могут быть получены без изменения формы данных - при условии, что соответствующие данные доступны, начиная с уже возвращенного bean.

beans не нужно полностью заполнять. Маршрутизаторы ORM имеют тенденцию лениво извлекать связанные объекты и коллекции, поэтому вы получаете рейтинг производительности за то, что именно вы получаете.

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

Ответ 2

Это шаблон дизайна, и самое главное - быть последовательным. На мой взгляд, DAO должны возвращать бизнес-объекты и не возвращать набор записей, если нет ОЧЕНЬ хорошей бизнес-причины, чтобы избежать этого. Если функция потенциально возвращает более одного объекта, она должна возвращать коллекцию объектов. Еще лучше, используйте фреймворк, такой как JPA или спящий режим, чтобы вы могли позволить инфраструктуре заботиться о сохранении.