A estas alturas casi todo el que se dedique a desarrollar aplicaciones que tengan que ver con bases de datos sabrá que significan las siglas ORM, pero por si acaso, vamos a explicarlo con un lenguaje sencillo:
Las bases de datos relacionales están pensadas para manejar conjuntos de datos, sin embargo los lenguajes orientados a objetos manejan objetos individuales, o listas (tuplas/arrays) de objetos, que suelen ser más complejos que los datos almacenados en las tablas de una base de datos relacional.
Cada una de las aproximaciones tiene sus ventajas e inconvenientes, pero de ello no voy a hablar en este post.
Object Relational Mapping es una técnica por la que la aplicación maneja objetos, pero guarda tablas. Es decir, es un adaptador entre la base de datos relacional y el modelo de objetos que maneja la aplicación.
Evidentemente esta explicación previa es para aquellos que no saben de que va el tema, para los expertos seguramente sobraba. Yo todavía soy un aprendiz en ORM.
Todo esto viene a cuento porque en la próxima gran revisión del programa PhotoGestión vamos a utilizar Firebird como base de datos y tiOPF como ORM, y continuamos con Delphi como lenguaje/entorno, por pura productividad (lo del Delphi).
¿Alguien tiene experiencia utilizando ORM? ¿Vale la pena liarse con esto o mejor programar como siempre?
Y haz probado db40?? es una base de datos empotrada que almacena objetos enteros. Yo la he probado un par de veces y me ofrece un buen rendimiento. En su site informan que la han usado en aplicaciones de tiempo real, asi que me parece seria una buena opcion.
Muchas gracias por la recomendación.
Si que estuve mirando lo de db4o el problema es que utilizo Delphi, tengo mucho código y mucha experiencia con éste lenguaje y entorno, por lo que, de momento, pasarme a .NET/Mono o Java para utilizar db4o no me compensa.
Evaluaste ECO III ? Que ventajas ofrece tiOPF sobre ECO
Sólo he jugado un poco con tiOPF, pero he leido sobre los dos. La principal baza para seleccionar tiOPF fue que el programa se va a desarrollar con Delphi 7, y ECO III (según he leido) es para .NET básicamente.
Anteriormente he trabajado con una aproximación a ORM de fabricación propia, pero evidentemente se quedaba a años luz de las comentadas. Aún así me mi solución me parece más light que las otras, cosa que tiene sus ventajas.
Yo una vez traté de montar un proyecto en un framework de persistencia, precisamente el tiopf ese que mencionas…
Mi experiencia fue un poco desalentadora, porque realmente esperaba mas de un framework de persistencia del cual se hablaba tan bien, tal vez es que las aplicaciones y requerimientos de los programas que hago son muy exigentes para este tipo de barbituros, el caso es que se me complicaba mucho la cuestión para generar reportes muy complicados, y terminaba haciendo la parte de reportes aparte del framework por lo que ya perdia chiste el asunto de hacerlo todo tan meticuloso.
otra cosa que me desanimó en la implementación es que al usar el framework estas poniendo una capa intermedia entre el motor de BD y la aplicación, con lo que algunos beneficios que pueden llegar a ser vitales en algunos casos se “semi*pierden” (como el poder cachar eventos de la base de datos por ejemplo)...vaya el caso era que para hacer cosas simples tenia que “brincarme” al framework y por lo mismo determiné que mejor me quedaba a como estaba, parece que los frameworks de persistencia todavía no son para mi
Saludos
La decisión de utilizar tiOPF fue en base a lecturas hechas por ahi y que un miembro del equipo lo estaba probando de forma particular y tenía una buena opinión.
Ahora llevo unos días un poco atareado y apenas he podido continuar las pruebas y las aproximaciones a dicho framework, pero me está resultando demasiado pesado, aún no he tomado la decisión definitiva, pero o me demuestra (el framework) que merece la pena utilizarlo o cambiaré a otro enfoque.
Respecto a lo de los reports, yo veo normal que para realizarlos sea necesario atacar directamente a la base de datos, por tema de rendimiento. Es más, yo no he visto todavía una aplicación que sea 100% orientada a objetos, SIEMPRE es necesario escribir un procedimiento almacenado, una consulta o actualización en SQL que la aplicación lanza contra el servidor y siempre por temas de rendimiento.
Hola, a todos, tengo que desarrollar una aplicacion OO en lenguaje “Python” y base de datos “mysql”, ¿alguien podria aconsejarme una ORM? Me han hablado de SQLobject…¿es la mas potente?
Lo siento Pablo, pero para Python no conozco nada.
Quisiera saber como termino la historia, estoy tratando de decidirme a tiopf (por cuestión de portabilidad (fpc)), me gusta la idea de los test unitarios que de la forma tradicional no se me ocurren. Saludos
@rolly, pues al final no utilizamos tiopf, sino instantobjects (http://www.instantobjects.org/), lo entendimos desde el principio y nos resultó más comodo, pero eso son apreciaciones totalmente subjetivas.