fez писал(а) 14. Февраля 2007 :: 06:26:Чем вот это отличается от многократных ЗагрузитьВнешнююКомпоненту?
Обсуждение ушло не в ту степь.
1) Я говорю не столько о загрузке плагинов, сколько о разделении функционала 1С++ на отдельные модули, что даст определенные удобства пользователю. Представь, что разделение произошло и в результате получилось 20-30 модулей? Нет, конечно, желающие пользоваться конструкцией "ЗагрузитьВнешнююКомпоненту" и vkloader пусть ими пользуются, это их личное дело. Мне же было бы неприятно во все конфы с использованием 1С++ вставлять лишние 20-30 строк. И добавлять новые по мере расширения функционала 1С++.
2) Мой вариант загрузки плагинов дополнительно обеспечивает
обратную совместимость со старыми версиями 1С++. Отсутствие такого механизма потребовало бы изменений конфы для перехода на новую версию.
3) Вариант с объектом "1С++.Ядро" это всего лишь пример решения проблемы, когда разным конфам нужен различный набор модулей 1С++ (причем разных версий). Это, в общем-то, не самый удобный вариант, хотя он все равно лучше ручного прописывания загрузки всех необходимых модулей. Если у меня штук 15 разных конф используют один набор модулей, то, если я добавляю в набор пару новых модулей или убираю 1-2 ненужных, мне не понадобится руками править все эти 15 конф.
4) Почему я говорю о проблеме модульности? Я всегда рассматривал 1С++ как разработку, обеспечивающую развитие платформы 7.7. Т.е. я считаю ее не просто компонентой с большим функционалом. Более того, я считаю, что 1С++ выросла из понятия "компонента", теперь это уже, скорее, пакет, "сервис-пак". Поэтому для дальнейшего развития нужно подумать о модульной архитектуре. Почему, например, 1С не написала один здоровый мегаэкзешник, в который было бы все включено? Почему в МС-Офисе используют большой набор DLL, а не пару больших экзешников winword.exe и excel.exe? Потому что отдельные модули быстрее и удобнее разрабатывать и ими удобнее пользоваться.
Лично я согласен, что добавлять новый функционал в уже сильно распухшую компоненту, не очень хорошо. Программисту вместо разработки нового функционала придется потратить много времени для обеспечения корректного включения нового кода в существующий. Новый функционал увеличит и без того большую сложность кода 1С++, в нем будет труднее разбираться. Включение всего функционала в один модуль снизит общую надежность системы.
Не знаю, отсутствие ли модульности тому виной (но очень может быть), но вот уже очень большой отрезок времени я просто не вижу, чтобы в 1С++ добавлялся принципиально новый функционал. Происходит простое развитие существующего. А отсутствие нового - это отсутствие развития. Отсутствие развития - это смерть.
artbear писал(а) 14. Февраля 2007 :: 04:42:А что делать в этом случае, если плагины используют один и тот функционал - например, классы и их внутренний функционал используются во многих частях 1С++ - ТП, АктивИкс и т.д. ?
Каким образом предполагается организовать межплагинное взаимодействие?
Переход на плагины не обязательно должен происходить сразу. Это наверняка приведет только к лишним глюкам. Лучше это делать постепенно. Для начала можно написать просто элементарный загрузчик. Этот загрузчик мог бы загружать текущий вариант 1С++ как плагин. Новый функционал уже лучше оформлять в виде плагинов. Ну и в дальнейшем уже постепенно выделять объекты в отдельные плагины.
Взаимодействовать плагины могут по тому же механизмы, что и модули 1С: через dllimport. Т.е. загрузчик в первую очередь загружает "плагин" под именем 1cpp.dll, который содержит функционал для работы с классами, а остальные плагины будут к нему подлинковываться автоматически. В ActiveX, насколько я понимаю, основная зависимость - это CComponentClass? Вот этот класс и можно сделать экспортируемым через dllimport/dllexport.
Страницы: 
Тихо стало... (число прочтений - 13413 )
