Обсуждение:Сохранение в поток (постановка)
Хочется, чтобы код нового сохранения в поток не был похож на существующий, который можно охарактеризовать как пример классического спагетти-кода. Следует четко разделить подсистемы записи-считывания данных, получения информации о структуре базы данных, синхронизации объектов, организации диалога с пользователем и, собственно, кода сохранения в поток. Для записи информации следует создать абстрактный базовый класс (АБК) -- writer -- от которого наследовать два класса: BinaryWriter и XMLWriter. Аналогично сделать для класса, который будет считывать и разбирать поток при загрузке объектов в базу. Похожую иерархию (АБК и два наследника) стоит предусмотреть и для объекта, предоставляющего информацию о структуре БД. Наследниками АБК в этом случае будут два класса: использующий информацию из гедыминовского объекта atDatabase и напрямую обращающийся к RDB$ таблицам.
AndreiK 00:14, 21 January 2007 (CET)
Возникает проблема при сохранении в поток документов, у которых обязательно есть ссылка на COMPANYKEY, через которую затягивается в поток компания.
Предлагается сделать два режима: сохранение настройки и сохранение данных. В первом случае вместо ИД текущей компании сохранять спец код, который на другой базе заменять на ИД текущей компании на той базе. Во втором -- сохранять как и раньше.
AndreiK 17:51, 9 January 2008 (CET)
Нужно предусмотреть защиту от повторной загрузки файла на эту же базу.
AndreiK 18:45, 28 January 2008 (CET)
Все таки идея с группированием записей одного типа по своим клиент-датасетам и потом запись этих датасетов в общий файл не хороша. Вопрос в том, где держать эти датасеты? В памяти? Но, никакой памяти не хватит для сохранения большой базы. Правильнее все-таки писать в поток запись за записью, но максимально сократив количество служебной информации на каждую запись.
