Ver Mensaje Individual
  #50  
Antiguo 10-10-2007
rolandoj rolandoj is offline
Miembro
 
Registrado: abr 2007
Posts: 395
Reputación: 18
rolandoj Va por buen camino
Smile Algunas aclaraciones

Cita:
Empezado por mamcx Ver Mensaje
Eso no serviria por la sencilla razon de que las cosas externas se mueven de forma impredecible, como es el caso de las librerias de acceso a datos.

Es muy diferente el modelo de acceso a datos de odbc-oledb por ejemplo... tanto que mezclar todo es un embrollo.

Ademas, es un error de diseño tener algo que "parece" igual pero funciona diferente. Eso introduciria bugs invisibles o problemas de desempeño que no serian previstos.... por ejemplo, el pasar de un acceso de archivos en paradox a un modelo desconectado en sql server.

Ahora, siguiendo la idea del articulo, intercambiar la libreria de acceso no es tan dificil... Renombrar clases, ajustar parametros... a lo sumo, con la documentacion necesario toma 1 dia... y hablo basado en experiencia, he usado todas las opciones del Delphi, mas las de VS desde la version 6, y foxpro, y python, y asp. Es realmente fastidioso escribir la mismas cosas de forma diferente pero teniendo una sola clase es un trabajo de carpinteria.

Mas dificil eso si son los controles visuales y el sistema de reporteo...
Hola,

Respeto tú opinión; pero no la comparto.

Parte de la metodología de portabilidad es usar solo cosas standard. Con ello, a mí las cosas me han trabajado bien y rápido, y como dije antes, he pasado sin problemas entre diferentes motores, incluyendo versiones del mismo motor y drivers para el mismo motor. Los problemas de cambio se dan entre drivers, casi sin excepción, cuando se usan características que no son standard.

Ahora, disculpame la observación; pero creo que no te ha tocado desarrollar aplicaciones realmente extensas y/o complejas en código; o bien no te colocas en el caso de quienes usen metodologías diferentes a la tuya.

Dependiendo de la metodología hay diferentes necesidades y una cosa es emplear utilidades de reemplazo de cadenas de caracteres, y otra tener que, como obliga dbExpress sobre BDE en muchas de las metodologías usadas, recodificar segmentos completos.

En una aplicación que requiera fuertemente de cambios manuales, y que tenga centenares de formas, con docenas de miles de líneas de código, no es viable hacer el cambio en un tiempo remotamente cercano a un día. Si fuera así, esas aplicaciones tomarían menos de un mes, y todos sabemos que las aplicaciones realmente grandes toman usualmente más de un año.

Para ilustrar estos problemas, considera que dbExpress no soporta el filtrado, y piensa en lo que pasa al recodificar completa cada parte con eventos OnfilterRecord.

Te doy otro ejemplo, que además cubre lo del unidad que emula BDE.

Empiezo diciendo que, aunque hay algunas molestias (eso es otro tema); después de hacerla, cada aplicación me funciona bien practicamente con tan solo recompilar (podría incluso hacerse sin cambios si no fuera por un problema de diseño Delphi). Respecto que hacerlo así sea un "error de diseño", cada quién puede hacerse su propia opinión, por mi parte, y hablo por experiencia, estoy en total desacuerdo contigo. Lo de los problemas "invisibles" depende de que tan bien elaborado esté el código y de la metodología con que se trabaje.

Sus ventajas en rapidez y confiabilidad, dependiendo de la codificación, son enormes. El ejemplo es el caso del método Prepare. En TSQLQuery, no existe; su equivalente sería :

Prepared := True;

Por tanto, se podría decir "tan solo usa una utilidad de reemplazo de string"; pero que pasa si la aplicación tiene otras clases para las que se ha definido un método Prepare ?. Así tocaría realizar todos los cambios de esa índole uno a uno. En mi caso, tan solo creo un método Prepare con la línea Prepared := True;

Finalmente pensemos que una aplicación bien diseñada requiere tener módulos de datos lo más específicos posibles, así que en una realmente grande estamos hablando de docenas de ellos. Hay que ver lo que significa entonces revisarlos uno a uno. Y eso es solo lo correspondiente a módulos de datos.

Bueno, sobre todo eso hay mucho que se puede comentar; pero este hilo es para hablar lo que pasa con los problemas de Delphi en el mercado, y sobre eso creo que ya he expresado mis ideas

Saludos
Responder Con Cita