В настоящее время у нас есть подсистема прямых запросов, которая позволяет получить результат выполнения запроса в ТЗ или ИТЗ. Мне кажется, можно развить немного тему обмена данными между различными модулями компоненты. Например, чем плоха загрузка результатов запроса в ИТЗ? Тем, что подсистема прямых запросов обязана знать про существование ИТЗ и уметь с ней взаимодействовать.

Мне кажется, в этом случае можно использовать другое решение, которые уменьшит связность между модулями и даст в наше распоряжение гораздо больше возможностей. Я имею в виду создание интерфейсов для обмена данными между различными объектами. Например, подсистема прямых запросов экспортирует некоторый интерфейс, через который любой модуль, поддерживающий этот интерфейс, сможет получить данные. Таким образом, задача получения результата запроса в ИТЗ будет решаться не на стороне подсистемы прямых запросов, а на стороне ИТЗ, через интерфейс.

Плюс другие модули смогут получать данные запроса. Например, это можно использовать в построителе отчетов, создание которого не за горами. Или это можно использовать для обмена данными между Йокселем и ИТЗ - например, можно будет через интерфейс получить содержимое табличного документа в ИТЗ и как-то манипулировать этими данными: сортировать, группировать, сворачивать и т.д.

artbear писал(а) 21. Марта 2008 :: 14:14:

Лучше не надо. Это старая хрень, сделанная во многом наспех.

artbear писал(а) 22. Марта 2008 :: 09:46:

Вообще-то имеется в виду как раз интерфейс. Возможно, не в смысле COM-интерфейса, а интерфейс в смысле C++: абстрактный класс с чисто виртуальными функциями.

kms писал(а) 24. Марта 2008 :: 13:31:

Я имею в виду данные, того типа, что обычно хранятся в объектах типа ТЗ или ИТЗ. В этом случае просто будет получение массива объектов CValue для строки. Или ты хочешь от CValue совсем отвязаться?

Если отвязываться от CValue, то сразу вылезают следующие проблемы:
- numeric-тип: должен быть тип, адекватный CNumeric. С произвольным количеством разрядом и без потерь точности в представлении дробных чисел.
- date-тип. В принципе, можно взять из Буста. Хотя вроде бы диапазон дат поддерживает меньший.
- что делать с объектами типа "документ" и "справочник" (и др.)? Промежуточный служебный тип? В принципе, можно, но возникнет оверхед на конвертировании из CValue и обратно.
- агрегатные объекты, которые не являются объектами данных. В принципе, можно их вообще запретить.

В общем, не знаю, стоит ли возня с этими проблемами отвязывания от CValue?...

kms писал(а) 24. Марта 2008 :: 14:15:

Если реализовать взаимодействие через обычные экспортные классы, то плагинная подсистема на COM-интерфейсах становится реализуемой в виде некоторого модуля , который транслирует вызовы между оберточными классами и COM-интерфейсами Просто прямая работа с классами C++ как удобнее выглядит

Правда, блин, когда прокси-класс строится на shared_ptr (он является своего рода реализацией IUnknown), то временем жизни объекта управлять проще. А вот, что делать, когда он на scoped_ptr или аналоге? Как тогда вернуть объект при помощи метода другого объекта? Временем жизни тогда управлять становится гораздо сложнее. Получается, надо выдирать из Буста не scoped_ptr, а все-таки shared_ptr И фиксировать его в качестве "межмодульного стандарта указателя".

Если использовать COM, то тогда все равно получается ограничение на используемые типы данных. Например, нельзя использовать CValue. Как будет, например, происходить маршаллинг для этих объектов? А если все же использовать CValue, то как будет задействоваться CValue в модуле на VB? Как-то выглядит все это так, что COM в силу своей универсальности, сильно ограничивает возможности взаимодействия. Или, как минимум, это взаимодействие усложняет. Т.е., если раньше можно было взаимодействовать "напрямую", то в случае COM понадобится заводить несколько специальных интерфейсов.

kms писал(а) 24. Марта 2008 :: 14:47:

Вот я и говорю, если полная совместимость с COM-технологией, то будет оверхед по скорости и усложнение взаимодействия. Если все просто и быстро, то несовместимо с COM, но можно в конце концов присобачить специальный модуль-коннектор.

kms писал(а) 24. Марта 2008 :: 14:47:

Это если использовать COM. А если не использовать, то тогда вопрос жизни объекта нужно решать. shared_ptr, ИМХО, вполне на высоте.