Cita:
Empezado por rolandoj
O bien no te colocas en el caso de quienes usen metodologías diferentes a la tuya.
|
Puede ser. O mejor dicho, simplemente apunto a que hay maneras de disminuir significativamente los riesgos que eso plantea.
Un aspecto que es *crucial* es tener separado la logica de negocios del acceso a datos y tener una capa de ORM entre la logica y el acceso a datos. Si se mete codigo dentro de los TDataSet que no sea presentacional - o mejor dicho, no deberia existir nada de codigo alli - o si se hace SQL "clavado" en el codigo que no sea el minimo estandar, y cosas por el estilo, no hay de otra que rechequear todo. Eso es claro... y precisamente por eso fue que me puse a investigar. En el grupo de CodeGear oodesing aprendi un monton al respecto....
Cita:
Empezado por rolandoj
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.
|
Pues he ahi el problema. Es algo para pensar: PORQUE hay que hacer cambios manuales?
Es posible crear un soporte desde 0 a una aplicacion madura, con miles de lineas de codigo?
Pues si!. De hecho hace un mes hice exactamente eso.
http://code.djangoproject.com/ticket/5062
Le cree el soporte a django para Sql Server 2000/2005, haciendo varias emulaciones (como la implementacion de LIMIT/OFFSET que usa mysql), integre algo del codigo que habia por alli (las definiciones de tipos de datos) pero casi el 70% lo escribi yo. Luego vino otro tipo:
http://code.djangoproject.com/ticket/5246
y lo puso mas chulo. Tonces lo cogi y le hice otras mejoras.
En total, no me tomo mas de 15 horas de trabajo directo... y la mayoria fue mirar como era el asunto (no soy para nada experto en python. Me meti en el asunto porque vendi una tienda que necesitaba Sql Server y no habia programadores de django con experiencia en Sql Server).
Ahora la leccion no es que soy un super-programador, o que el cambio fue tan simple o que python es tan sencillo. La arquitectura del sistema permite este tipo de asuntos, y es porque esta desacoplado a todo nivel... lo que complica el diseño pero facilita los cambios. Y eso a pesar que todo el sistema estaba pensado para soportar mysql/postgree con sus propias idiosincracias que no trasladan o eran en opinion de algunos imposibles, a sql server.
Cita:
Empezado por rolandoj
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
|
Por lo que logro entender de tus aportes, no veo que haya un error de diseño ni estaba pensando que los tuvieras. Tenes BDE y lo vas adaptando a diversos entornos, y utilizas wrappers para ajustar las diferencias. No solo es una opcion adecuada, es la correcta.
El error seria por ejemplo, coger ADO.NET y "invisiblemente" hacerlo pasar como ADO. Eso no traslada. La arquitectura de BDE no traslada muy bien a la de dbexpress. Aunque quizas la de dbexpress se parece conceptualmente a ADO. En fin....
De todas maneras, lo que mencionas es un testimonio solido de las ventajas de Delphi y lo que se puede hacer si se activa la neurona
. Eso es gracias en parte, a que a pesar de las gracias que hacen los productores de plataformas y los mismos de Borland en ir re-inventando ruedas ves tras vez, al menos no como el caso de MS, podemos seguir con la rueda "viejita" y darle una lustrada para que quede como nueva.
Mientras hayan programadores capaces que usen Delphi, y estos sigan expandiendo sus habilidades, no hay de que preocuparse!