Как использовать объекты доступа к данным для доступа к данным по сериализованным и реляционным базам данных

Question

Я занимаюсь разработкой библиотеки классов модели домена C ++, которая должна предоставить некоторые средства или среду (например, классы интерфейса и т. Д.) Для записи / чтения данных экземпляра класса в / из двоичного файла и РСУБД. Основой для этой библиотеки является приложение, которое использует СУБД, и существует несколько методов, которые создают экземпляр класса, выполняя последовательность вызовов извлечения и обновления базы данных для извлечения коллекций данных членов. Доступ к сериализованным данным имеет другой способ организации данных, поэтому я хочу, чтобы модель предметной области полностью игнорировала первичные / внешние ключи, идентификаторы и т. Д.

Чтобы решить эту проблему, я подумываю использовать шаблон Объект доступа к данным (DAO) и хотел бы получить несколько советов о «гранулярности», времени жизни и использовании объектов DAO (в ваших ответах: обратите внимание, что я буду использовать C ++, а не Java, и что класс домена не может содержать никакой информации ID / ключа из RDBMS или хранилища двоичных файлов):

1. Есть ли у каждого экземпляра Foo объекта домена свой экземпляр FooDAO или для всех экземпляров класса Foo существует один экземпляр FooDAO?
2. FooDAO создается один раз для каждого экземпляра Foo, или экземпляр FooDAO будет создаваться только тогда, когда необходим доступ к данным, и уничтожаться сразу после этого?
3. Страница J2EE в DAO представляет DTO в дополнение к DAO. Почему DAO не может передавать данные?
4. Для сложного класса домена Foo, который имеет экземпляры других классов домена Bar, кажется неизбежным, что класс FooDAO использует класс BarDAO для извлечения данных. Это приведет к параллельным иерархиям / зависимостям в структуре классов домена и структуре классов DAO. Как это можно сделать лучше всего?

Спасибо за вашу помощь!

Answer 1

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

Некоторые мысли в произвольном порядке:

• Иметь отдельный экземпляр объекта DAO для каждого экземпляра в БД. Если у вас есть общий экземпляр, может возникнуть проблема с синхронизацией потоков, и вам придется делать много копий.
• Мои библиотечные классы DAO используют типы, тесно связанные с типами RDBMS, по нескольким причинам. Во-первых, библиотека поддерживает автоматическое создание и обновление хранилища в базовом хранилище данных, поэтому классы должны иметь достаточно информации для создания таблиц. Во-вторых, это делает переход данных намного проще и оптимизируемым (например, вы можете делать прямые копии данных ODBC / OLEDB с использованием собственных интерфейсов). Недостатком является то, что в объектах DAO не может быть «хороших» типов классов (например: строковые абстракции с большим количеством данных, чем фактический строковый буфер).
• Я создаю по требованию, конечно, потому что в хранилище потенциально гораздо больше данных, чем было бы целесообразно поместить в память.
• Я стараюсь сохранять классы DAO простыми, с минимальными функциями доступа и «близкими» к базовым структурам данных. Это означает, что нет наследования от других классов DAO, экземпляры имеют ключевые переменные-члены и т. Д.

Помимо классов DAO я создаю более доступные классы, которые представляют данные в моем приложении и могут или не могут отображать 1-1 в класс DAO. Они могут иметь любой тип членов и структуру, должны быть теми, которые использует приложение, и иметь методы для копирования данных в / из классов DAO, которые лежат в их основе.

Надеюсь, это поможет.

Answer 2

Я не знаю наилучшей реализации, но вот что я видел:

1. Отдельно для каждого экземпляра.
2. Создан прямо перед тем, как понадобиться, и уничтожен сразу после.
3. Не знаю.
4. Объединить данные вне экземпляров DAO, тем самым избегая связи.

Отказ от ответственности: это именно то, что я видел, сделано.