por que delphi2005 tubo que ligarce a asp

[cahosoft]

la mayoria de nosotros sabe, que las herramientas de microsoft (en este caso asp)... solo corren en ambeinte guindows (windows) y no hay posbilidad de trabajar con con otros S.O.... ademas que herramientas como jsp y el mismo php tienen ventajas mucho mayores a una arquitectura como asp....

yo era un seguidor asiduo de borland... pero esta nueva version de delphi no me gusta por la dependencia que este tiene a microsoft.....

BUENO ESTA ES MI OPINION......

[Jan]

Hola Cahosoft,

la verdad es que me llaman mucho la atención todas estas manifestaciones que se han estado produciendo en los últimos meses acerca de que Borland se ha vendido a Microsoft y todas estas cosas. No es por nada, pero Delphi siempre ha estado vinculado a Windows y construido sobre pilares de Microsoft como es el API Win32. Me parece natural que si Microsoft está preparando la jubilación de Win32 en favor de una nueva plataforma de programación, como en .NET, Borland haga lo mismo con Delphi. Lo contrario sería jubilar esta herramienta de programación. Se puede argumentar que Borland lanzó al mercado Kylix como una versión de Delphi para Linux, pero seamos sinceros, nunca le han dado un empuje lo suficientemente fuerte, es mas creo que nunca han terminado de creer en esa herramienta. Además, también existen proyectos como Mono o dotGNU que hacen que, en realidad, los desarrollos con Delphi 2005 (o Delphi 8), sean mas portables que nunca. En definitiva, si esta versión no te gusta por la dependencia de Microsoft, no te ha gustado ninguna, porque esa dependencia siempre ha existido.

[Al González]

¡Hola!

Contundente respuesta Jan, estoy de acuerdo contigo.

Turbo Pascal 5.5 ya corría en MS-DOS, y entonces no nos quejábamos tanto. Lo se, los tiempos y los precios (y la calidad :() han cambiado. Pero debemos seguir buscando esa necesaria unificacion de tecnologías de información que se dará tarte o temprano. Mono es una verdadera cachetada con guante blanco a la miopía de Microsoft, ¿qué estamos haciendo los demás al respecto?

Un abrazo.

Al González :).

[mamcx]

Yo era un seguidor asiduo de borland... pero esta nueva version de delphi no me gusta por la dependencia que este tiene a microsoft.....

BUENO ESTA ES MI OPINION...... No creo que se tenga un problema directo con usar el SO de MS, de hecho, en parte el que haya un sistema de escritorio como windows y que MS haya tenido un exito tan vasto a permitido que "pequeños" jugadores tengamos un chance en este negocio, porque como era antes, quien podria tener acceso a un mainframe?

Sin embargo, el problema de la dependencia es real. Pero esta dependencia si ocurre de forma fuerte es culpa nuestra, de no entender la economia detras del software. Por sea como sea habra dependencia: Si usamos open source, tambien la habara. Corremos linux? dependemos del kernel de la distribucion, etc.. Hacemos PHP? dependemos del lenguaje como tal. El punto no es malo en si, lo malo es tener una dependencia muy fuerte.

Por ejemplo, esta el .NET. Pues, y que tiene de malo? Es un API menos sucia que el de win32, es mas confortable para programar y ademas es un páso OBLIGATORIO para MS... Ademas, acaso nosotros no hicimos transicion de un codigo procedural auno OO? De hecho, me asombraba que MS no tuviera su API OO. .NET es como un puente a ello. AHora, que haya una real necesidad de usarlo es otra cosa. Para mi, el .NET por ahora y hasta que salga longhorn es para servidores, web y webservices y punto... despues ya vere...

Ahora bien, la dependencia ocurre por no saber elegir ni dimensionar las cosas. No saber cual mercado es el que estamos atacando.

Por ejemplo, si nuestros clientes tienen mayormente equipos de escritorio y sus "servidores" pues son los mismos de escritorio, con mas memoria, quizas, tonces no hay de otra: Corremos MS. Nos podemos aguar la boca con usar linux pero el mercado de escritorio no es un blanco muy bueno, por ahora. Como alguien dijo: la plataforma determina el tamaño maximo del mercado posible. Si la plataforma es Sql server, el mercado maximo es todos los que usan Windows2000 y superior menos todos los usarios de casa menos todos los que usan otra BD.

Si es un sector empresarial ALTO, Java y punto. Si es sitios web, tal vez PHP o quizas ASP.NET, quien sabe.

Pero una vez establecida la plataforma de ahi en adelante corremos por nuestra cuenta: Todas las decisiones que tomemos seran nuestra responsabilidad.

Es indiscutible: hay que pegarse de las plataformas que use o demande los clientes: Office, .NET, Sql Server, Oracle, Linux, Java, etc... Pero se deberian ver como asuntos externos a nuestro sistema; el codigo sino es portable es por causa nuestra, no por el uso de X cosa. Un codigo bien hecho no deberia causar lios a la hora de pasar de motores de BD, ni de un ambiente C/S a uno windows. Deberia formarse por "nucleos" y "puentes" y "logica de negocio". Los nucleos serian funciones comunes, codigo comun, ciclos for pendejos, ifs aqui y alla, whiles por aca.

La logica de negocio es el codigo especifico y concreto. Es poco reusable (logica de contabilidad no sirve para hacer un servidor FTP, obvio) y NO deberia por NADA del mundo hablar directamente a la plataforma y al API, debe usar puentes.

Los puentes es en donde esta la clave de la libertad. Encapsular llamadas a api por medio de puentes. Un ejemplo de un puente de BD:



type
TAccesoDatos=class(TObject)
FCon:IConexionDatos;//Nadita de TADOConnectio aui, ok?
public
function EjecutarSql(Sql:String):TClientDataSet; //Sino te gusta este,
consiguete otro dataset con codigo fuente en memoria o hazle un wrapper
function EjecutarSqlNoDatos(Sql:String):Integer;//para insert, delete,
etc...
ActualizarDatos(Datos:TClientDataSet);

type
TParserSql
public
CrearSelect(Tabla:String,Campos():String;Filtro:String=''...
CrearInsert...
CrearDelete...



O algo asi. Una clase de estas no presenta muchos lios de dependencia, puede funcionar con Firebird como con Sql server. Noten que agrege un CrearSelect, de hecho, hacer en el codigo hardcode lcSql:='SELECT * FROM Tabla' es un camino seguro a una dependencia. Pero un metodo o mejor una clase que se encarge de armar los SQL de acuerdo al dialecto especifico de la BD es mas flexible y de hecho, no muy dificil. Incluso en un proyecto reciente tengo un parser de Sql que se le asigna una cadena sql y lo convierte en objetos tablas, campos, filtros, ordenes y lo manupilo como objeto y NO concatenando caracteres, y no toma mas de 1 semana hacerla.

Como ven, nada de si estamos usando ADO o FibPlus o quien sabe que. Nada de que usamos la version ClientDataSet de IBExpress u otra. Nada de la versionXX de tal libreria de dataset. NADA, JAMAS de tocar la conexion por FUERA de la clase. Una clase de acceso a datos no son mas 10 funciones... Luego es permisible usar un DataSet en memoria si necesitamos o queremos o podemos hacer OO puro, ya es mas cuestion de gustos y necesidades...

Y asi, extender la idea. Quermos hacer archivos ZIP y usamos libreria tal. Pero si la usamos DIRECTAMENTE nuesto codigo tiene una dependencia muy fuerte. Pero mejor creamos un puente (wrapper como le dicen) y con codigo TCompresor.CrearArchivo, TCompresor.AgregarArchivos(Lista:TStringList) etc.. ahi libertar de pasar de ZIP a RAR o a CAB o lo que sea. Es usando wrappers que una empresa de software logra la mayor libertad posible. Incluso pasar de OS es no tan complejo de esa manera...

Luego estan otras decisiones. Si nuestro producto se fundamenta con Sql Server obviamente estamos vendiendole gratis a MS la plataforma de Sql server y TODAS sobre las que se base y posiblemente las relacionadas (como IIS, COM+, etc...). No tan malo: hay quienes lo desean asi, e igual ocurriria con MySql: Estamos vendiendo todas las plataformas sobre las que se base (los requerimientos) y potencialmente las relacionadas (como linux o apache o php).

Pero si luego un cliente nos pide una BD open source y no lo podemos pasar en cuestion de semanas, no fue culpa de MS; el que tengan un buen departamento de mercadeo no es excusa para que tomemos decisiones de negocio apresuradas.

Obviamente quedan 2 o 3 dependencias fuertes: El OS, el lenguaje y el API primario del lenguaje. Ya eso es cuestion de que queremos hacer y del mercado, y eso lo determinara cada cual.

Por mi parte, siendo programador agradecido de la plataforma de Windows nunca me a parecido que Borland provea una dependencia muy fuerte a ella. De hecho, a diferencia de mis colegas que desconocen que es posible usar motores sql embeidos, que el parser de IE de XML no es el UNICO que existe, que hacer un servidor HTTP no es tarea exclusiva de C++ y mucho mas, es con Delphi que se que hay otro mundo. Por otro lado, me permite hacer parte del ecosistema de Windows sin parecer alienigena como ocurre con Java.

De hecho, hace poco hubo un foro en un newsgroup de Borland donde se pregunto que clase de desarrollos hace la gente con Delphi e increiblemente, la GRAN mayoria de los que respondieron (no lo tomen como un hecho estadistico, ok?) respondio que no usan bases de datos y hace una amplia gama de desarrollos diferentes a los sistemas contables y todo eso. Lo importante es que no sonaba extraño al fin y al cabo. Pero por ejemplo, los 2 o 3 que hacen servidores Web con FoxPro parecen de otro mundo....

[Al González]

¡Hola a todos!

Mario:

¿Podrías acortar las líneas del código que pusiste, para leer mejor tu mensaje? ;)

Muchas gracias.

Al González :).