DAO предназначен только для доступа к базам данных?

Question

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

Разве шаблон DAO предназначен только для доступа к данным в базе данных?

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

Хотя я не согласен.Я мог бы иметь DAO следующим образом:

public interface CountryData {
    public List<Country> getByCriteria(Criteria criteria);
}

public final class SQLCountryData implements CountryData {
    public List<Country> getByCriteria(Criteria criteria) {
        // Get From SQL Database.
    }
}

public final class GraphCountryData implements CountryData {
    public List<Country> getByCriteria(Criteria criteria) {
        // Get From an Injected In-Memory Graph Data Structure.
    }
}

Здесь у меня есть интерфейс DAO и 2 реализации, одна, которая работает с базой данных SQL, и другая, которая работает, скажем, со структурой данных графа в памяти.Это правильно?Или реализация графа предназначена для создания в каком-то другом слое?

И если это правильно, каков лучший способ абстрагировать детали, специфичные для реализации, которые требуются каждой реализацией DAO?

Например, возьмите приведенную выше ссылку на класс I.Предположим, что это так:

public final class Criteria {
    private String countryName;

    public String getCountryName() {
        return this.countryName;
    }

    public void setCountryName(String countryName) {
        this.countryName = countryName;
    }
}

Для SQLCountryData необходимо каким-то образом сопоставить свойство countryName с идентификатором SQL, чтобы он мог генерировать правильный SQL.Для GraphCountryData, возможно, необходимо создать какой-то объект Predicate Object для свойства countryName, чтобы отфильтровывать вершины из неудачного графа.

Каков наилучший способ абстрагирования таких деталей без объединения клиентского кода, работающего противаннотация CountryData с деталями, относящимися к реализации, как это?

РЕДАКТИРОВАТЬ:

Пример, который я включил в класс критериев, достаточно прост, но подумайте, хочу ли я разрешить клиенту создавать сложные критерии, где они должны не только указывать свойство для фильтрацииon, а также оператор равенства, логические операторы для составных критериев и значение.

Answer 1

DAO являются частью DAL (уровня доступа к данным), и вы можете иметь данные, подкрепленные любым видом реализации (XML, RDBMS и т. Д.). Вам просто нужно убедиться, что экземпляр проекта внедрен / используется во время выполнения. В этом случае DI-фреймворки, такие как Spring / Guice, сияют. Кроме того, ваш Criteria интерфейс / реализация должен быть достаточно универсальным, чтобы захватывались только бизнес-детали (т. Е. Критерии названия страны), и фактическое сопоставление снова обрабатывалось классом реализации.

Для SQL, в вашем случае, вы можете либо вручную сгенерировать SQL, либо сгенерировать его с помощью вспомогательной библиотеки, такой как Spring, либо использовать полноценный фреймворк, такой как MyBatis. В нашем проекте файлы конфигурации Spring XML использовались для разделения клиента и реализации; это может измениться в вашем случае.

РЕДАКТИРОВАТЬ: Я вижу, что вы подняли аналогичную проблему в предыдущем вопросе. Ответ остается прежним. Вы можете добавить столько гибкости, сколько хотите в своем интерфейсе; вам просто нужно убедиться, что реализация достаточно умна, чтобы понять все аргументы, которые она получает, и соответствующим образом отобразить их в базовом источнике. В нашем случае мы извлекли объект значения из бизнес-уровня и преобразовали его в карту на уровне реализации SQL, которая может использоваться MyBatis. Опять же, этот процесс был в значительной степени прозрачным, и единственный уровень связи между сервисным уровнем и DAO через интерфейс определяемых объектов значений.

Answer 2

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

Из того, что я видел в реальном проекте, да, вы правы, вы должны предоставить различные реализации DAO для доступа к данным различными способами. В этом случае один дао переходит в БД, а другая реализация дао - в граф объектов.

Интерфейс DAO должен быть разработан очень тщательно. Ваши «Критерии» должны быть достаточно общими, чтобы инкапсулировать способ получения данных. Как достичь этого уровня развязки? Ответ может варьироваться в зависимости от вашей системы, в целом, я бы сказал, ответ будет «как обычно, добавив еще один уровень косвенности» :)

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

Чтобы свести к минимуму трудности с обслуживанием, я бы предложил вам использовать структуры управления зависимостями (например, Spring). Обычно эти фреймворки хорошо подходят для создания объектов DAO и хороших игр вместе. Удачи!

Answer 3

Нет, я не верю, что это связано с только базами данных. Аббревиатура предназначена для Data Access Object, а не для «Объекта доступа к базе данных», поэтому ее можно использовать с любым типом источника данных.

Весь смысл в том, чтобы отделить приложение от резервного хранилища данных, чтобы хранилище могло быть изменено по желанию, при условии, что оно все еще следует тем же правилам.

Это не означает просто переключение Oracle и размещение в DB2. Это также может означать переход на решение, не основанное на СУБД.

Answer 4

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

DAO - это «объект доступа к данным», а не «объект доступа к базе данных».Следовательно, везде, где вам нужно CRUD-данные в / из (например, файл, память, база данных и т. Д.), Вы можете использовать DAO.

В домене, управляемом дизайном, существует шаблон репозитория.Хотя Repository как слово намного лучше, чем три случайных буквы (DAO), концепция та же самая.

Целью шаблона DAO / Repository является абстрагирование резервного хранилища данных, которое может быть любым, что может содержать состояние.