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

Question

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

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

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

Благодарим за помощь!

Answer 1

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

Некоторые мысли, в частности, нет порядка:

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

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

Надеюсь, что помогает.

Answer 2

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

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

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