Re: Вопрос по дизайну и архитектуре COM+ компонент - COM/DCOM/ActiveX

Как лучше сдизайнить объект который бы использовался различными типами клиентов: из ASP (VBscript) и из ISAPI DLL написанной на С++

идея вся в том чтобы обеспечить независимость веб-серверного кода (ASP) от структуры базы данных запихнув всю работу с SQL в COM+ объекты

Понятно что тут дело первой важности придумать хороший интерфейс
какие рекомендоации по
1.способу доступа к БД (ADO, ODBC, OLEDB)
2.потоковая модель для компоненты (Apartment,Both,Neutral)?
компоненты всегда будут out-of-process т.е. маршаллинг имеет место быть. вопрос в каком случае он будет быстрее осуществляться. подозреваю что ASP использует STA модель(?)
3.использование дополнительных компонент (COM, не COM+) как внешних библиотек
возможны ли подводные камни тут?
4. обмен данными между COM+ и клиентом: VARIANT array, список BSTR-ов или готовый объект? (например ADO recordset)
например у меня есть объект Customer с кучей параметров (имя,адрес,телефон и т.д.)

1. ADO — удобный и достаточно скоростной
2. Neutral обычно работает быстрее и требует меньших ресурсов, но сложнее писать. В большинстве случаев вполне достаточно Apartment
3. Использование COM компонент из COM+ компонент? Если эти COM обьекты не работают с базой и не требуется поддерживать транзакционность, то особых проблем, связанных с COM+, думаю что не будет
4. Массив, строка или рекордсет имеют примерно одинаковую производительность. Я предпочитаю ADO рекордсет, так как с ним удобнее работать.

Здравствуйте andsm, Вы писали:

A>1. ADO — удобный и достаточно скоростной
у нас используется в данный момент ODBC для доступа из С++,
и ADO из ASP. тут нужна некая унификация, но мне кажется что ADO
будет медленнее чем ODBC(?). сам не сравнивал, лишь предполагаю

A>2. Neutral обычно работает быстрее и требует меньших ресурсов, но сложнее писать. В большинстве случаев >вполне достаточно Apartment
Майкрософт рекомендует для COM+ Neutral или MTA. если я поставлю Both, ничего плохого же
не должно быть? тогда потоковая модель не будет зависеть от типа клиента

A>3. Использование COM компонент из COM+ компонент? Если эти COM обьекты не работают с базой и не требуется >поддерживать транзакционность, то особых проблем, связанных с COM+, думаю что не будет
с базой точно не будут. это компонента шифрования паролей и работы с кредитными карточками
(связана по HTTP с внешним провайдером — электронным банком)

A>4. Массив, строка или рекордсет имеют примерно одинаковую производительность. Я предпочитаю ADO рекордсет, так как с ним удобнее работать.

наверное да, рекордсет можно рассматривать как 2-мерный массив переменной длины в который
можно что угодно запихать. мне собственно нужно будет шоппинг карту реализовать

Здравствуйте andsm, Вы писали:

A>4. Массив, строка или рекордсет имеют примерно одинаковую производительность. Я предпочитаю ADO рекордсет, так как с ним удобнее работать.

Я делал VARIANT array, получается применением метода GetRows объекта ADORecordset. Потом этот массив возвращал клиентам.
Удачи.

Здравствуйте Аноним, Вы писали:

А>Как лучше сдизайнить объект который бы использовался различными типами клиентов: из ASP (VBscript) и из ISAPI DLL написанной на С++

А>идея вся в том чтобы обеспечить независимость веб-серверного кода (ASP) от структуры базы данных запихнув всю работу с SQL в COM+ объекты

А>Понятно что тут дело первой важности придумать хороший интерфейс
А>какие рекомендоации по
А>1.способу доступа к БД (ADO, ODBC, OLEDB)

ODBC уже давно устарел

ADO (через OLEDB) — основная технология доступа к базам данных у Microsoft. Рекомендуется использовать родной OLEDB-провайдер для работы с базой данных (если нет OLEDB-провайдеров, можно использовать OLEDB-провайдер для ODBC).

Если говорить о производительности, то ADO и OLEDB обеспечивают примерно равную производительность, ODBC намного медленнее.

А>3.использование дополнительных компонент (COM, не COM+) как внешних библиотек
А>возможны ли подводные камни тут?

проблем быть не должно

А>4. обмен данными между COM+ и клиентом: VARIANT array, список BSTR-ов или готовый объект? (например ADO recordset)
А>например у меня есть объект Customer с кучей параметров (имя,адрес,телефон и т.д.)

Используй ADO Recordset.
Остальные способы использовать не рекомендую (строки или variant array необходимо будет разбирать на клиенте, это не очень удобно, нет проверки типов передаваемых данных).

Если необходимо выводить данные в виде Grid'ов, отчетов Crystal Report и т.п., то и здесь ADO Recordset — оптимальное решение.

SMS>Используй ADO Recordset.
SMS>Остальные способы использовать не рекомендую (строки или variant array необходимо будет разбирать на клиенте, это не очень удобно, нет проверки типов передаваемых данных).

SMS>Если необходимо выводить данные в виде Grid'ов, отчетов Crystal Report и т.п., то и здесь ADO Recordset — оптимальное решение.

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

т.е. строка вида "NAME=Vasya;LNAME=Pupkin;BALANCE=3.95;... "
конструировать ее можно с помощью класса-обертки, включающего
в себя упаковщик параметров и парсер

strParam = new CParamString();
strParam.AddValue("NAME",name);
strParam.AddValue("LNAME",lname);
// ...
pObj->Send(strParam.GetString());

а на стороне сервера

STDMETHODIMP Send(BSTR strParam)
{
   strParse = new CParamString(strParam);
   strParse.GetValue("NAME",&strName);
   strParse.GetValue("BALANCE",&nBalance);
   // ....
}

Здравствуйте Аноним, Вы писали:

А>больше собственно вопрос о том как передавать В компонент а не из него,
А>чтобы минимизировать число вызовов методов передающих параметры до одного.
А>я раньше делал кодированную строку в которой параметры описывают
А>сами себя
У вас клиент и сервер на разных машинах находятся или на одной?
По поводу DCOM. Я могу ошибаться, но насколько я понимаю, ситуация следующая.
Если мы работаем через рекордсет, происходят следующие вызовы:
pRst->get_Fields()->get_Item("field1")->get_Value. На одно поле приходится 3 вызова.
Если же работаем через IDispatch (ASP), то умножаем еще на 3.
Я прав или нет?

Множество интерфейсов за один раз не попросишь — объекты все разные.
Получаем некоторую нагрузку на сеть, с некоторыми задержками.
Вроде бы логичнее уменьшить число обращений, как вы и говорите. Разбирать рекордсет и
складывать в в BSTR, VARIANT или SAFEARRAY с этой точки зрения лучше, но возни больше.
А как вы смотрите по поводу XML? Если у вас SQL server, получаете от него данные в XML-е, запихиваете в строку и посылаете клиенту. То же самое можно делать и на сервере. Получаем от клиента XML, парсим его и делаем запрос к серверу.
Для этого не нужно писать свой парсер — можно воспользоваться MSXML. Если нужна информация
о типах данных — добавляете атрибуты (хотя, наверно, это излишне).
XML, полученный клиентом со стороны сервера трансформируете его на клиентской стороне
при помощи XSL и выдаете в браузер.
Посмотрите в эту сторону, может быть так будет проще в вашем случае?

Если же у вас клиент и сервер на одной машине, то не обязательно этот огород городить.
Можно, кстати, поискать информацию на эту тему. Может кто интересовался уже этим вопросом?
Я просто не встречал соответствующих статей. Был бы благодарен, если бы кто поделился
знаниями. Может есть какие исследований с красивыми диаграммами и циферками?

Успехов!

Здравствуйте WPooh, Вы писали:

WP>У вас клиент и сервер на разных машинах находятся или на одной?
WP>По поводу DCOM. Я могу ошибаться, но насколько я понимаю, ситуация следующая.
WP>Если мы работаем через рекордсет, происходят следующие вызовы:
pRst->>get_Fields()->get_Item("field1")->get_Value. На одно поле приходится 3 вызова.
WP>Если же работаем через IDispatch (ASP), то умножаем еще на 3.
WP>Я прав или нет? :shuffle:

ADO Recordset оптимизирован для передачи между машинами, т.е при пересылке происходит его полное перемещение с машины на машину. Для передачи используется формат ADTG — Advanced Data Tablegram Тем самым все вызовы вида pRst->>get_Fields()->get_Item("field1")->get_Value будут локальными, не нагружают сеть. Разборка рекордсета и складывание в BSTR, VARIANT или SAFEARRAY ведет к той же произодительности, но теряется удобство работы, самоописание данных + приходится писать дополнительный код, без которого вполне можно было бы обойтись. Использование XML несколько снижает производительность, так как необходимый обьем данных для пересылки в этом случае заметно превышает пересылаемый рекордсетом обьем данных — из-за различных тегов и недостаточно оптимизированного формата. Считаю что ADO Recordset в абсолютном большинстве случаев является лучшим транспортом для пересылки данных между уровнями, находящимися на различных машинах.

Кроме этого по архитектуре COM+ компонент — я предпочитаю компоненты без состояния. Они обеспечивают лучшую масштабируемость (по сравнению с компонентами с состоянием). В некоторых случаев специфика задачи может потребовать компоненты с состоянием, но в большинстве случаев можно использовать компоненты без состояния.

Здравствуйте Аноним, Вы писали:

A>>1. ADO — удобный и достаточно скоростной
А>у нас используется в данный момент ODBC для доступа из С++,
А>и ADO из ASP. тут нужна некая унификация, но мне кажется что ADO
А>будет медленнее чем ODBC(?). сам не сравнивал, лишь предполагаю

Я думаю ADO быстрее ODBC. Для MS SQL Server я это проверял — заметно быстрее, для остальных баз данных не проверял.

Здравствуйте andsm, Вы писали:

Спасибо за информацию.

Здравствуйте WPooh, Вы писали:

WP>Здравствуйте Аноним, Вы писали:

WP>По поводу DCOM. Я могу ошибаться, но насколько я понимаю, ситуация следующая.
WP>Если мы работаем через рекордсет, происходят следующие вызовы:
pRst->>get_Fields()->get_Item("field1")->get_Value. На одно поле приходится 3 вызова.
WP>Если же работаем через IDispatch (ASP), то умножаем еще на 3.
WP>Я прав или нет? :shuffle:

думаю что нет. ибо рекордсет целиком передается на клиентскую машину
и все вышеуказанные вызовы происходят с локальным объектом а не объектом на сервере

WP>А как вы смотрите по поводу XML? Если у вас SQL server, получаете от него данные в XML-е, запихиваете в строку и посылаете клиенту. То же самое можно делать и на сервере. Получаем от клиента XML, парсим его и делаем запрос к серверу.
WP>Для этого не нужно писать свой парсер — можно воспользоваться MSXML. Если нужна информация
WP>о типах данных — добавляете атрибуты (хотя, наверно, это излишне).
WP>Успехов!

в качестве эксперимента я написал собственный парсер XML-строк в виде класса-обертки.
структура данных для входных параметров простая (одномерная)
пример параметризованной строки передаваемой серверу:

<?xml version="1.0" ?>
<customer>
   <name>jta123</name>
   <password>Scizoid</password>
   <fname>Nikolay</fname>
   <mname>Y.</mname>
   <lname>Stepanov</lname>
   <street>911 Market St #6</street>
   <city>Atlanta</city>
   <state>GA</state>
   <zip>95104</zip>
   <countryid>149</countryid>
   <phone>381-781-0573</phone>
   <fax>390-328-5301</fax>
   <email>jta@att.com</email>
</customer>

использование на стороне сервера:

STDMETHODIMP CCustomer::NewAccount(BSTR strParam)
{
   XMLParamString params(strParam);  // XML string from BSTR

   BSTR strName = params.GetValue(L"name");  // extract parameters
   BSTR strPassword = params.GetValue(L"password");
   BSTR strFName = params.GetValue(L"fname");
   BSTR strMName = params.GetValue(L"mname");
   BSTR strLName = params.GetValue(L"lname");

   // :-)
   while(DoNothingLoop() )
   {
      //
   }

   MakeGeneralProtectionFailure(); // Windows cleanup :-)

}

A>Кроме этого по архитектуре COM+ компонент — я предпочитаю компоненты без состояния. Они обеспечивают >лучшую масштабируемость (по сравнению с компонентами с состоянием). В некоторых случаев специфика задачи >может потребовать компоненты с состоянием, но в большинстве случаев можно использовать компоненты без

в случае использования в COM+ пула объектов компоненты обязательно должны быть stateless.
в противном случае приватные данные КОМ-класса созданные одним клиентом будут портиться другим клиентом между вызовами.

	От:	Аноним
	Дата:	31.07.02 23:50
	Оценка:

	От:	andsm
	Дата:	01.08.02 04:56
	Оценка:

	От:	Аноним
	Дата:	01.08.02 05:35
	Оценка:

	От:	Максим Алексейкин
	Дата:	01.08.02 08:30
	Оценка:

	От:	SergeMS
	Дата:	01.08.02 09:34
	Оценка:

	От:	WPooh
	Дата:	03.08.02 08:17
	Оценка:

	От:	WPooh
	Дата:	03.08.02 09:52
	Оценка: