Mensaje enviado por "BERMUDEZ KRIPAK, CLAUDIO CESAR" <CBERMUDEZK@repsol-ypf.com>

Gente:

Lejos de poder aclarar algo, creo que voy a agregar un poco mas de confusión.
Todo lo que dicen respecto al objeto ADODB.COnnection es muy cierto, implementado así como lo mencionan.
Pero, en mi opinión, si está tomada la decisión de usar Componentes 'ActiveX', hay que hacerlo como dictan las normas del fabricante. :-)))

Cualquier método público de un COM requiere información de entrada (a través de sus argumentos) y ocasionalmente puede también devolver información (como resultado de una función). La idea de implementar el desarrollo así, responde al modelo de 3 capas propuesto por Microsoft, "y no a otra cosa". Los "ActiveX.DLL" y "ActiveX.EXE" son para eso, independientemente de que alguien los quiera darles otro uso. (Pensemos que también Access se usa en algunos casos para brindar servicios de BD, como si se tratara de un motor de 'fortaleza industrial', lo cual es una verdadera 'utopía')

El intercambio de información entre COMs, se basa exclusivamente en los tipos de Datos típicos de VB, y como una excepción, Microsoft ofrece la posibilidad de devolver Objetos Recordset como resultado de un método (algo excelente !!). Esto es muy claro por la tremenda potencia que ofrece este tipo de objeto, que sirve además para Intercambios de tipo OLE con Excel y Word.

Por otro lado y siempre en un ambiente de 3 Capas, no es entendible el objetivo de pasar ADODB.Conecction entre capas, no se me ocurre para qué ?, si se supone que solamente es la Capa de Datos (la última) la que debe dialogar con la BD. A las capas restantes, y mucho menos a la Interfase (sea VB o ASP) debe importarle que es, como se llama, ni de que se trata la BD.

Por otro lado si pensamos que filosóficamente los COMs son objetos del tipo ACID (En la MSDN: ACID=Atomicity, Consistency, Isolation, Durability), tener una sesión abierta contra una BD genera un alto riesgo de pérdida de información y consumo de recursos inútiles del lado del DB-Server, y un hueco tremendo en la seguridad. (Esto está muy optimizado en MTS ,porque hace 'pooling' de conexiones a BD, y no desperdicia nada a la hora de conectarse.)

Por otro lado es poco eficiente (siempre dentro del modelo) la tranferencia de Objetos como argumentos de métodos entre COMs, porque si bien en la mayoría de los casos son pasados por referencia, si los COMs corren en áreas de memoria de su propio proceso, estos objetos pasados se volverán a copiar (de ida y vuelta) cada vez que los COMs se comuniquen entre sí, generando un 'overhead' de p...m... !!

Piensen las aplicaciones en 3 capas, desarrollen así y pongan, si es posible, los COMs en MTS, y verán, como me pasó a mí (que también me resistía a incorporarlo), que los tiempos de procesamiento, como mínimo, se reducen a la mitad.

El modelo de 3 capas es, casi al revés que los demás desarrollos informáticos, de muy sencilla implementación, aunque si resulta mas complejo a la hora del diseño conceptual de la aplicación.

En mi opinión, creo que COM y ADO es lo mejor que ha hecho Microsoft desde que sacó el Windows 3.11.

Un abrazo.
claudio.