Visual Basic, .NET, ASP, VBScript
 

   
   
     

Форум - VBA

Страница: 1 |

 

  Вопрос: отличия dll Добавлено: 14.01.10 11:27  

Автор вопроса:  fifa36
Здравствуйте! Подскажите почему некоторые библиотеки можно подключать как COM, а для других прописывать подключение в коде
типа kernel32
Отличие в коде этих библиотек?

Ответить

  Ответы Всего ответов: 3  

Номер ответа: 1
Автор ответа:
 VβÐUηìt



Вопросов: 246
Ответов: 3333
 Web-сайт: смекаешь.рф
 Профиль | | #1
Добавлено: 14.01.10 11:31
Итак, "технология COM". Аббревиатура COM расшифровывается просто, это - Component Object Model - компонентная объектная модель. Иногда говорят и "модель COM". Сутью данной технологии является то,что программы строятся из компонент, которые состоят из объектов. Само по себе это обстоятельство не является последней новостью в области программостроения - модульная архитектура и объектно-ориентированный подход к построению программ давно являются признанными стандартами de facto. Новостью является то, что является этими компонентами и объектами - ими является непосредственно исполняемый двоичный код. Да-да, не "включаемые исходные тексты" компилируемые совместно с проектом, не "библиотеки стандартных программ", присоединяемые линкером, а непосредственно исполняемые файлы, которые никак не надо "связывать" со своим проектом - их достаточно зарегистрировать в операционной системе и они будут доступны любой программе исполняющейся на данной машине. Т.е. их использование в своей программе производится "без использования операций сборки модуля".

Это ли новость? Такая технология называется "динамическая загрузка", она давно известна и её преимущества очевидны. А модули, которые позволяют загружать себя таким образом, называются DLL. И в системе, именуемой Microsoft Windows такая технология известна от самого её рождения... А DLL и есть тот самый "двоичный исполняемый модуль", который может быть присоединен к программе лишь на стадии её выполнения.

Выходит, если весь проект распределить по нескольким динамическим библиотекам, то получатся "двоичные компоненты"?

Не совсем... Действительно, важнейший признак "компонентности" уже появится - исполняемую программу можно будет собирать из отдельных частей без операций сборки модуля. Но вот DLL - не компонента, DLL есть,если можно так выразиться, только "место обитания компонент" используемых в программе. Ведь из программы-то вызываются вполне конкретные процедуры и функции, которые только расположены в DLL. Кроме того, вызовы процедур "из своего модуля" и "из DLL" - не одинаковые действия. Вызов процедуры, которая располагается внутри "своего" модуля требует знания только имени этой процедуры, а если процедура располагается в DLL, то нужно знать ещё и имя самой библиотеки. Модель же COM позволяет этого "не знать", т.е. вызов объектов COM из своей программы осуществляется без знания того, где они расположены. Достаточно знать имя объекта.

Другое отличие COM, уже от привычных объектов в стиле объектно-ориентированного программирования (ООП), состоит в том, что объекты ООП известны только компилятору. Это - абстракции, в которых мыслит программист и которые компилятор превращает в двоичные структуры "данные + код". Объекты ООП существующие в разных единицах компиляции и, тем более, помещенные в разные двоичные модули, ничего не могут друг о друге "знать" просто потому, что их там нет и никогда не было. Не случайно заголовочные файлы, содержащие описания всех объектов проекта, подаются на вход именно компилятора - потом они уже никому не нужны. Объекты же COM - действительно существуют в двоичном виде как объекты. И в таком качестве известны всем, кто испытывает в них нужду.

Словом, если ограничить объём этого эссе, только ответом на вопрос "в чём суть?", то технология COM есть технология, которая переносит все преимущества ООП , доступные программисту на уровне исходного текста, на двоичный уровень. Если в исходном тексте программист волен использовать "те" объекты и не использовать "эти", но теряет всяческий контроль над тем, что он делал, как только исходный текст был скомпилирован, то при использовании COM эти возможности сохраняются на протяжении всего жизненного цикла программы. Дополнительно к этому добавляются возможности разделения проекта на отдельные, повторноиспользуемые, и двоичные компоненты. Т.е., если в результате непосильного труда у программиста получается что-то хорошее и нужное, хотя бы частично, кому-то другому, то, оформив это в виде COM-сервера, он смело может это распространять, не рискуя что-то потерять - ведь контроль за исходным текстом остается у него. В то же время все пользователи этого объекта будут его использовать так же, как и свой, "родной", объект. О других достоинствах COM мы поговорим в следующем выпуске.

Ответить

Номер ответа: 2
Автор ответа:
 fifa36



Вопросов: 33
Ответов: 116
 Профиль | | #2 Добавлено: 14.01.10 12:35
Спасибо! Кстати читал, эту серию частично). Но все таки тут сказано что DLL не COM просто потому что основная идея COM что нужно знать лишь имя COM объекта - а в DLL нужно знать еще и имя библиотеки.
Ну так вот что мешает зарегистрировать DLL в реестре в качестве COM. Должна ли библиотека быть написана в соответствие с какими- то правилами, чтобы иметь возможность быть COM?

Ответить

Номер ответа: 3
Автор ответа:
 Sharp


Лидер форума

ICQ: 216865379 

Вопросов: 106
Ответов: 9979
 Web-сайт: sharpc.livejournal.com
 Профиль | | #3
Добавлено: 14.01.10 14:00
В обычной DLL экспортируются просто функции, которые сразу можно исполнять. А COM DLL предоставляет доступ к COM-объектам в ней, экспортируя только 4 функции: DllRegisterServer/DllUnregisterServer для регистрации и наоборот этой библиотеки, DllGetClassObject для возвращения указателя на class factory, которая может создавать COM-объекты, реализованные в этой DLL, и DllCanUnloadNow для проверки на 0 всех счетчиков ссылок.

Ответить

Страница: 1 |

Поиск по форуму



© Copyright 2002-2011 VBNet.RU | Пишите нам