На мой взгляд COM сделан очень качественно и я себе могу только предстваить сколько разных систем на него завязано, что по сути тормозит .NET ужасно. Тут MS лажанулись, поскольку нельзя делать системы которые работают очень стабильноВсёже непонятно, почему их не устраивает COM технология, пусть даже интерпретируемая CRL.
чтобы пользователи и разработчики не зацикливались на них...вот она сырмяжная правда жизни.Лепсик, да я знаю, что ты владеешь предметом. Думаю, и знаешь ты в разы больше, чем я. Я просто про терминологию. Ты говоришь неточно, отсюда и непонимание может быть. Потом.--Строго говоря, объект сервера COM не обязан быть AciveX.
да я догадываюсь
1) Ну, опять ты, блин, начинаешь в одну кучу всё валить. Понятно дело, что прямой вызов быстрее. Но интерфейсы то разрабатывают для повторного применения бинарного кода. А вот здесь без COM и не обойтись, если хочешь не просто повторно применять код, но применять его по-людски в коде различных входных яззыков программирования. Назначение у COM - одно единственное - способ получения переносимого кода и облегчение использования этого кода в других программах при повторном применении кода dll. Всё, больше ни для чего COM не нужен.мой поинт ис - стоимость интерфейсов (создания поддержки, отладки) выше чем прямой вызов функции в коде с исходными текстами.
если мне возможно без огорода обойтись - стараюсь обходится
Просвятите, плз., как же это можно приладить взаимодедйствие между процессами при помощи COM в качестве "... идея для взаимодействия между приложениями и ...".По правде говоря мне COM нравился всегда, и как идея для взаимодействия между приложениями и как компонентный подход и интерфейсы. Все там красиво, только единственное что непортабельно на конкурирующие платформы, так что тут понятно куда ветер дует.
Абсолютно непонятная фраза. Так нужна тебе поддержки COM или нет? Или ты поддерживаешь COM без поддержки COM? Крут товарищ, однако.Lepsik писал(а): если мне возможно без огорода обойтись - стараюсь обходится
Да, нет, tasko. Лепсик там другое сказал. Он сказал, что для многих задач, когда деплоится приложение, пусть даже состоящее из многих модулей, то часто можно обойтись без COM в своих приложениях и для своего же проекта. И это правильно, если для клиентов возможна схема апгрейда софта, когда им в будущем будут подсовывать только пропаченные dll. В виде COM, на мой взгляд, разумно офрмлять некий функционал, который ты потом можешь продавать отдельно от всего остального да ещё другим клиентам. Или когда над одним проектом работает публика на разных языках программирования.Lepsik:
если мне возможно без огорода обойтись - стараюсь обходится
Абсолютно непонятная фраза. Так нужна тебе поддержки COM или нет? Или ты поддерживаешь COM без поддержки COM? Крут товарищ, однако.
Так вот прикол в том, что если Лепсик оформит свои изыски в виде обычного API, то он потеряет большую аудиторию почитатеоей-покупателей, что программиро\руют на VB, VBA или Дельфи. Если же гига мысли будут оформлены ввиде COM - то объем продаж для виндозников-девелоперов будет значительно шире.
Это ты про примитывные компоненты?tasko писал(а):Не надо гнать на COM. Классная вещь все-таки. Два приложения, абсолютно ничего не знающих друг о друге, взаимодействуют друг с другом, обеспечивая при этом довольно таки крепкую устойчивость от ошибок. Е-мое, мечта.
Обхожусь насколько это возможноtasko писал(а): Абсолютно непонятная фраза. Так нужна тебе поддержки COM или нет? Или ты поддерживаешь COM без поддержки COM? Крут товарищ, однако.
Ты забыл про пирожок добавитьмолодец VG ты правильно понял мою мысль.
Сам знаешь, это невозможно для проф проги. Если уж никуда не деться, то на худой конец создают новый интерфейс. Нельзя менять интерфейсы для конечного пользователя. На этом COM держится. Это допустимо только "для себя", когда проект в опытной эксплуатации.А уж если интерфейс поменяли (ну подумаешь аргумент у одной функции поправили) - лазий в врапеперах и правь.
Ты ... эта .... для хранения - бинарники, что в проекте, прекомпилед всякие убивай - глядишь проекты будут меньше по размеру "исходников"То ли дело - лежит 10 мегов текстов в прожекте и все под рукой.
Правильно ли я тебя понял, что у тебя классы, которые содержат по 2-3 тыс. public or protected методов и пропертей? И ты этим пользуешься? 2-3 тысячи?Это ты про примитывные компоненты?
У меня прекрасно живут с классы с 2-3 тыс. функций и пропертей в каждом. И никакаих комов. И никаких усилий по созданию интерфейсов
Легко. COM-компонент в одной из своих ипостасей есть обычного вида DLL со своей DllMain(...). При наличии shared секции и некоторой фантазии - незаменимый инструмент.vg писал(а):ura,
Просвятите, плз., как же это можно приладить взаимодедйствие между процессами при помощи COM в качестве "... идея для взаимодействия между приложениями и ...".
vg писал(а):2 Лепсик,
--Ты забыл про пирожок добавить
возьми с полки
Они их содержат. я в лучшем случае 5-10% использовал.vg писал(а): Правильно ли я тебя понял, что у тебя классы, которые содержат по 2-3 тыс. public or protected методов и пропертей? И ты этим пользуешься? 2-3 тысячи?
Не совсем так, если читать о чём шла речь выше.... То, что Вы пишите, конечно, работает, но относится просто к DLL...vg:
ura,
Просвятите, плз., как же это можно приладить взаимодедйствие между процессами при помощи COM в качестве "... идея для взаимодействия между приложениями и ...".
Легко. COM-компонент в одной из своих ипостасей есть обычного вида DLL со своей DllMain(...). При наличии shared секции и некоторой фантазии - незаменимый инструмент.
в использовании COM. Нет. Смотря какие сервисы нужно предоставлять клиентам от сервера, сетевой инфраструктуры были (и есть) удобными разные по сложности технологии и техники - DCOM, CORBA, PIPE, RPC, ну и сокеты, конечно, да и в конце концов SCM/SCC. Сейчас публика SOAP любит (или говорит, что любит). Этот список можно продолжить, особенно если говорить о высокоуровневых средствах других языков и фреймворков. Хотя эти технологии нельзя, конечно, мешать в одну кучу, ибо они предоставляют программисту совершенно разный уровень сервисов, протоколов и соответственно возможностей для создания клиент\серверных приложений.Таким образом можно реализовать вполне полноценную client/server модель. До этого альтернативой были только сокеты, не так ли?
Наиболее простой для программиста технологией (реально жизненной только в сетях W2k c AD, да и то, при условии несложной сетевой инфраструктуры) является DCOM, на мой взгляд. Простота в том, что практически ничего программировать не надо. Однако за пределами W2k - это не живёт. Тупик. Ибо единственное, что отличает COM от обычной DLL, это то, что загрузкой, подсчётом ссылок клиентов, выгрузкой и т.д. DLL (COM) - управляет операционная система, а не программист. Поэтому и говорят в технической литературе иногда - COM сервер и клиент COM сервера. Это действительно здорово, когда в своих клиентских приложениях вы имеете возможность использовать COM сервера, например, ArcGIS, что установлен на вашем компе. При этом разные ваши приложения могут одновременно использовать одни и теже COM-объекты ArcGIS (он выступает в виде сервера COM-ов). Раньше это приходилось делать руками. Например, подгружать DLL из exe-шника (для загрузки DLL не обязательно иметь файл с расширением dll. exe - пойдёт )ArcView 3.1 (было и такое ПО когда-то), для обмена с ним командами по отрисовке в теме ArcView чего-то.