Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Noticias
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Colaboración Paypal con ClubDelphi

 
 
Herramientas Buscar en Tema Desplegado
  #21  
Antiguo 10-10-2007
rolandoj rolandoj is offline
Miembro
 
Registrado: abr 2007
Posts: 395
Poder: 20
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
 



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Actualizar los puestos de un programa instalado en el servidor VRO Conexión con bases de datos 3 19-07-2005 20:53:16
Refresco automático en todos los puestos??? burasu Conexión con bases de datos 6 10-02-2005 11:19:40


La franja horaria es GMT +2. Ahora son las 22:25:51.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi