Ventajas e inconvenientes de VCL.NET

[johurgi]

Buenas a tod@s.

Tengo un problema con la nueva plataforma de programción de Borland. Mi problema es el siguiente.

Tengo implementada mas de la mitad de mi aplicacion en VCL estandard de borland con la cual me funciona todo. Al adquirir el nuevo paquete de desarrollo de borland hemos decicdido empezar a desarrollar los nuevos modulos a VCL.NET, cual es mi sorpresa que algunas de las librerias que tenia en la VCL no las tengo en VCL.NET, el intercambio de datos con las librerias mias que ya tengo implementadas en VCL no funcionan correctamente si el programa esta implementado en VCL.NET.

Mi pregunta es la siguiente que ventajas tengo con la VCL.NET, cuando mi aplicacion es de escritorio (intranet) normalmente un solo usuario(1 pc) un 70% de las ocasiones. O que inconvenientes me voy a encontrar por continuar el desarrollo con VCL de cara un futuro.


Gracias de antemano.

[dec]

Hola,

Sé perfectamente que todo lo que diga podrá ser utilizado en mi contra, pero, en fin, me atreveré a decir lo que recuerdo haber leído sobre la VCL .NET y sus posibles usos y su razón de existir.

La plataforma .NET de Microsoft proporciona Servicios (Clases, Componentes) para prácticamente todo lo que se necesita: y siempre se puede contar con componentes de terceros, algo así como ocurre en Delphi.

La VCL .NET que presenta Borland se supone que puede servir de ayuda para desarrolladores que quieran portar sus aplicaciones a la plataforma .NET de Microsoft: la VCL .NET se encarga de trabajar contra dicha plataforma, pero, manteniendo el nombre de algunas clases, funciones, procedimientos, etc.

Ahora bien, portar una aplicación para Win32 hecha con la VCL de Borland a la plataforma .NET de Microsoft no es algo sencillo (como ya sabes) incluso contando con la ayuda de la VCL .NET, que, como digo, se supone que trata de ayudar, y probablemente lo haga en algunos casos.

Desde luego, no se puede (en aplicaciones de más o menos envergadura) recompilar para la plataforma .NET de Microsoft, ni siquiera haciendo uso de la VCL .NET, que, por otro lado, tampoco se planteó para que solucionara este problema: recompilar una aplicación de Win32 a .NET... sin más.

Hay que pensar además que migrar una aplicación a la plataforma .NET no es necesario, quiero decir, parece que las aplicaciones escritas en Delphi (para Win32) funcionarán sin problema en el nuevo Windows Vista, con pocos o ningún cambio, como puede leerse en el artículo: Creating Windows Vista ready applications with Delphi (http://www.installationexcellence.com/articles/VistaWithDelphi/Index.html) (gracias Neftalí por el enlace).

Puede haber muchos motivos para utilizar la plataforma .NET, para desarrollar aplicaciones para esta plataforma, pero, desde luego, no parece que sea algo de necesidad, teniendo en cuenta que Windows Vista (que aún no salió al mercado) mantiene compatibilidad hacia atrás en ese sentido (en mi opinión sería de locos no hacerlo) e incluye el API de Win32, que es contra la que trabajan en última instancia las aplicaciones programadas con Delphi.

Así pues... dadas las dificultades de migración, habría que plantearse detenidamente si esta es necesaria, viendo que una aplicación funcionará correctamente en Windows Vista... y probablemente en sucesivos Windows (para lo que pueden pasar unos cuantos años, téngase en cuenta que Windows XP lleva con nosostros desde hace ya cinco o seis años, y que Windows Vista acaso tenga el mismo tiempo de vida o más).

Se dice, se comenta, acaso se sepa, que Windows prepara un Windows .NET, es decir, un sistema operativo que se base en la propia plataforma .NET (del alguna manera, no digo que sea exactamente así) y, en ese caso, las aplicaciones escritas para la API de Win32 no funcionarán y la migración se hará obligatoria... necesaria.

Pero, para Windows .NET queda todavía bastante (lo suficiente como para plantearse la escritura de nuestra aplicación utilizando ya los Servicios de la plataforma .NET) y, en todo caso, probablemente incluso en Windows .NET se mantendrá cierta compatibilidad hacia atrás; ocurre lo mismo con aplicaciones de MS-DOS, que pueden ejecutarse en Windows XP mejor o peor.

Terminaré dando mi opinión, que, por supuesto, tiene que cogerse con pinzas. Personalmente, en caso de plantearme la migración de una aplicación a la plataforma .NET trataría de utilizar los Servicios de dicha plataforma sin contar con la VCL .NET que proporciona Borland. Mejor dicho -porque al fin y al cabo acaso podría considerarse la VCL .NET como una serie de componentes "de terceros" que pueden usarse en la plataforma .NET-, digo, procuraría no atarme a la VCL .NET, no ceñirme a ella, sino hacer el esfuerzo y aprender lo que sea menester de los propios Servicios de la plataforma .NET y hacer uso de ellos.

Al fin y al cabo la VCL .NET hace eso: enmascara el uso de los Servicios de la plataforma .NET pero de modo que la VCL .NET se parezca, sea similar (y en algunos casos igual) a la VCL para Win32. Esta última utilizaba el API de Win32, aquella utiliza el API de la plataforma .NET. Es un intermediario, básicamente, del que podemos prescindir, evidentemente, si somos capaces de interactuar de forma directa con los Servicios de la plataforma .NET.

En fin. No quiero enrollarme mucho más, porque tal vez he dicho demás, quiero decir que no me parece que sea yo el más indicado para decir mucho más sobre este tema... acaso algún compañero pueda aportar su granito de arena, como yo he tratado de aportar el mío, y bueno, en todo caso, podemos seguir hablando sobre esto si te/os apetece.

[johurgi]

Gracias por tu respuesta, la verdad es que me has aclarado mucho.

La opcion que adoptado ha sido la de continuar con lo empezado con la VCL estandard, y a partir de ahora utilizar la VCL.NET para proyectos nuevos.