mapeo objeto-relacional (más conocido por su nombre en inglés, Object-Relational mapping, o sus siglas O/RM, ORM, y O/R mapping) es una técnica de programación para convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional. En la práctica esto crea una base de datos orientada a objetos virtual, por sobre la base de datos relacional. Esto posibilita el uso de las características propias de la orientación a objetos (básicamente herencia y polimorfismo). Hay paquetes comerciales y de uso libre disponibles que desarrollan el mapeo relacional de objetos, aunque algunos programadores prefieren crear sus propias herramientas ORM. (Fuente Wikipedia)
Propongo el siguiente ejemplo:
- Una Persona tiene una o mas fotos (hasMany).
- Una Foto tiene asociada una Persona (belongsTo)
En codigo para guardar la asociacion sería:
$arreglo['Persona']['nombre'] = "Fabian"; $arreglo['Persona'][]['Fotos']['nombre'] = "Bailando.jpg"; $arreglo['Persona'][]['Fotos']['nombre'] = "Cantando.jpg";
$objeto->guardar($arreglo);
Deseo ahora updatear:
$arreglo['Persona']['id'] = 1;
$arreglo['Persona']['nombre'] = "Fabian Ramirez";
$objeto->guardar($arreglo);
Y mas aun borrar:
$objeto->borrar(1);
Y leer:
$objeto->read(1);
Lo cual me retornaria un arreglo asi:
$arreglo['Persona']['nombre'] = "Fabian Ramirez" $arreglo['Persona'][0]['Fotos']['nombre'] = "Bailando.jpg"; $arreglo['Persona'][1]['Fotos']['nombre'] = "Saltando.jpg";
Y si leyera la foto me retornaria:
$arreglo['Fotos']['nombre'] = "Bailando.jpg"; $arreglo['Fotos']['Persona']['nombre'] = "Fabian Ramirez";
¿Deseas tener ORM (Object Relational Mapping) sin usar un framework complejo para tus proyectos?
Aquí te dejo una lista con los frameworks ya incorporados que puedes utilizar:
Yo personalmente use Propel para un pequeño desarrollo y me trajo MUY buenos resultados.
¿ Tu cual usas ?
No hay Trackbacks
19 Comentarios
CakePHP que tiene su propio ORM. Igualmente hay que tener un poco de cuidado con los ORM, ya que en muchos casos resultan un tanto ineficientes, sobre todo para grandes consultas.
Muchas veces es por ineficiencia de los usuarios tambien
, por lo que se debe tener cuidado y saber muy bien que es lo que estaba pasando por debajo.
A la moda a la moda.
Buen ejemplo, similar a los que hace CakePHP. Ahora estoy creando uno propio para la empresa en la que estoy, devolviendo objetos de datos y no arreglos, pero la idea es la misma
Saludos y nos vemos el vierneees!
Para que te devuelva objetos seria:
$objeto = $objeto->read(1);
echo “Mi nombre es ” . (string)$objeto->nombre . ” y apellido ” . (string)$objeto->apellido;
A la moda a la moda
Para guardar
$persona = new Persona(“Fabian”,”Ramirez”);
$objeto->save($persona);
Saludos
Mas o menos asi, como lo planteas, pero con get y set (son los requerimientos que la empresa pide
)
$persona = $object->read(1);
echo “Mi Nombre es ” . $persona->getNombre() . ” y mi novio se llama ” . $persona->Novia->getNombre() . “”;
Y para guardar algo similiar
$data->setNombre(‘Victor’);
$data->Novia->setNombre(‘Elizabeth’);
$persona->save($data);
Saludos
No es “novio” es “novia”
para que no se preste para malos entendidos jajajaja
Eso se llama accesadores y modificaciones .. se parece a cuando trabajaba Java sin Hibernate
Saludos
claro. Asi mismito mijo.
Es preferible en cualquier caso el uso de un array asociativo como DTO
Correcto, pero mucha influencia java hace que pidan esas cosas…
De todas formas ya tengo todo solucionado por detras para manejar los datos a nivel de sistema como arreglos y a nivel de aplicacion como objetos.
Lo malo es que el argumento más fuerte a favor de los accesors/mutators es que permiten un control, a nivel de lógica de negocio, del contenido del DTO, cuando por definición un DTO es un objeto para transporta data, independiente del contexto en que estos objetos se utilicen y por lo tanto NO deben contener lógica, para eso existen otras capas.
Justamente Pablo y de acuerdo contigo .. pero anda a quitarle de la cabeza a una persona que modela UML lo que estamos hablando .. siempre para cada propiedad de una clase .. hay un accesador y modificador …
Pablo: esta bien lo que dices de los DTO, pero en este caso se esta hablando de ORM, en donde, si bien no creo que corresponda tener lógica de negocios dentro de un getter/setter, estarÃa bien tener minima funcionalidad como validaciones, encriptadores o lo que se te ocurra.
De todas formas, coincido con Favicon en que el uso “obligatorio” de getters/setters es una herencia de Java sin mucho fundamento en aplicaciones de mediana envergadura.
Concuerdo en lo que dice Pablo, pero asi son los requerimientos.
Aunque en si, el objeto de datos no da muchas funcionalidades solo get y set (en mi caso obviamente).
Saludos
Leito:
Lo que mencionas de las validaciones, encriptaciones, etc, no corresponde a la capa de transporte (DTO) sino al modelo, DAO, o como quieras llamarlo. Por ejemplo si hubiera que hacer una validación deberÃa ser en el save(), o en algún metodo similar, porque eventualmente yo querrÃa utilizar el DTO en forma incompleta (por ejemplo en el caso de un usuario, si el proceso de creación se hiciera por pasos)
Saludos,
@Victor: tamos de acuerdo
Muy cierto Pablo lo que dices …
Feliz con el resultado que dio todo esto .. ayudo a todos.
Saludos
Obviamente que ayudo a todos, buenisimo el post y la discusión que se dio muy buena.
Saludos
PD: Ahora a mi objeto de datos le agregué dos métodos mas, toArray() y toObject() que me simplificaron un poco mas la vida.
Es posible autogenerar las clases con cakephp sin necesidad de mapear todo paso a paso ?