[quote author=kms link=1214205575/240#242 date=1215728213][quote author=orefkov link=1214205575/240#241 date=1215717470]В-целом то я согласен с тобой. Есть частности - например, при выгрузке результата запроса количества строк я не знаю.[/quote] Ага, понял. Тогда вот так пока: [code] // источник может передавать 0, если количество не определено // приемник может возвращать 0, если ограничений нет // если приемник реально не может принять данные, пусть возвращает ошибку virtual HRESULT ldrInit(DWORD& nColCount, DWORD& nRowCount) throw() = 0; [/code]
Пошел пока путем максимального упрощения, чтобы понять чего не хватает. Понял пока вот что: - "ПараметрыДляПриемника" - так и не захотелось использовать. Вижу, у тебя используется для параметризации очистки, но в общем случае у меня получается параметров больше. Например, я хочу загружать данные в строку или колонку ТЗ, при этом могу обрезать исходные данные до одной строки, а могу слить все строки в одну - и т.д. Короче, прокси-объекты в качестве кастомизированных приемников представляются предпочтительными.
- setColumn упростил в пользу AddColumn - применения colIdx не нашел.
- Вот что хотел спросить у тебя - assignRetValue - тоже не вижу применения. У меня все приемники - это живые контексты, после выгрузки - это контексты с данными. Нужен ли будет assignRetValue?
P.S. Ну, наверняка чего-то будет не хватать, вот жду этого момента. :) На выгрузке из строки ИТ в вектор пока пожеланий не проявилось.[/quote]
Так, по порядку.
Зависимости текущего интерфейса от sqlite нет - параметр объявлен указателем на предварительно продекларированную структуру sqlite3. Как говорится - не нужен, не используй. А мне для будущего развития может пригодится.
Виртуальный деструктор - ну это я по привычке, gcc любит ворнинги кидать, когда класс с виртуальными функциями не имеет виртуального деструктора.
AddRef/Release тоже ни к чему - мой метод выгрузки нисколько не собирается сохранять ссылки на объект приемник либо удалять его.
Параметры для приемника - ну, тебе не нужны, а мне допустим нужны. Если они есть, то хуже не будет - позволяет реализовывать более гибкие сценарии использования.
Присвоение возвращаемого значения: опять же твой сценарий - это очень частный случай. Посмотри например у меня IScalarResultLoader. К тому же какой код проще: [code] Приемник = СоздатьПростейшийЗагрузчикВоЧтоТо(); запрос.Выполнить(Приемник); Результат = Приемник.ПринятыеДанные(); [/code] или [code] Результат = запрос.Выполнить(СоздатьПростейшийЗагрузчикВоЧтоТо()); [/code]?
setColumn vs addColumn colIdx у меня используется в IVTResultLoader. Даже если посмотреть общую семантику интерфейса - раз в методе init уже указывается количество колонок, то далее нужен именно set а не add. В первоначальном варианте интерфейса у меня как раз было так - в init количество колонок не указывалось, и был метод addColumn. Однако когда я начал реализовывать загрузчик не в пустую ТЗ, а уже содержашую колонки - вот тут и пришлось изменить интерфейс.
Ограничение количества принимаемых строк - делать в инит имхо неверно - приемник может не знать, сколько строк ему надо выкачать, но должен иметь возможность остановить приемку (например, приемник с какимнить условием типа "Пока общий итог сумм документов меньше 100000"). Я собирался изменить void addValues на BOOL addValues - при возврате FALSE остановить выгрузку.
Вот примерно так.
И такой вопрос Даже перейдя на IUnknown-ые интерфейсы, остается вопрос перехода от CValue/CBLContext к IUnknown, те тот же rtti и dynamic_cast. Так стоит ли овчинка выделки?
|