Me cayo la ficha. Modelos, Mappers, Zend_Db, Doctrine..

[RatoN7]

Buenos dias.

Solo quiero comentar algo que entendi hace poco sobre el tratamientos de los datos, saber si lo entendi bien y tambien conocer otras formas de manejarse.

Hace algunos meses venia programando con CodeIgniter. El cual es un framework simple y facil. La forma de crear modelos que utilizaba era solo de crear funciones con consultas a la DB que traian y formateaban los datos para que lo utilice el controlador o la vista. Todo muy bien, en las cosas complicadas utilizaba mucho SQL en un minimo de consultas para optimizar lo mas posible.

Ahora, vengo utilizando Zend Framework. La forma de utilizar los modelos es muy diferente a como lo venia haciendo yo, antes traia y llevaba arrays(u objetos stdClass, que es lo mismo) con datos, mientras que ahora son objetos bien formados que son instancias de su propia clase del modelo.

Como ya venia aprendiendo bastante me anime tambien a usar Doctrine 2. Usaba Doctrine y Zend_Db a medias. Para poder aprender como usarlos, ver diferencias y saber cual es la ventaja/desventaja de cada uno.

Al principio no podia entender porque se me hacia tan complicado hacer un join con Zend_Db_Table, o porque esta clase te selcciona siempre todos los campos de la tabla, incluso tambien no podia entender porque Zend_Db recomienda utilizar el count de php despues de traer todos los datos en vez de hacerlo desde mysql COUNT (Estaba acostumbrado en hacer todo en un minimo de consultas con joins, counts, etc y traer solamente los datos que iba a utilizar)
Con doctrine tambien parecido, para actualizar se debe traer primero el objeto, luego cambiar sus atributos y despues grabarlo en la db(me parecia ilogico hacer dos consultas si sabia que podia hacer solo una).

Hay muchas mas cosas que no entendia, pero no me voy a explayarme en eso. Lo que quiero indicar es que me acostumbre a optimizar lo mas posible mysql haciendo las menos consultas posibles y trayendo los datos necesarios. Siempre que podia en las cosas complicadas tambien venia mysql en ayuda, utilizaba UNION SELECT, (JOINs, de todo tipo), COUNT, CONCAT, etc etc etc.
Pero bueno, despues de trabajar por un tiempo con Doctrine y Zend_Db creo que entendi bien su funcionamiento y quiero explicar lo que entendi. Si hay algo mal, u otras formas de manejarse por favor haganmelo saber, la idea es seguir aprendiendo.

Zend_Db
Segun entendi por el quick start y otros ejemplos, el modelo es la estructura del objeto, con sus atributos, setters y getters. El DbTable, el que hace la conexion con la base de datos. Y el mapper, es el que interactua con los dos anteriores, armando los objetos del modelo al traer los datos del Dbtable, o grabando los objetos en la base de datos.
El formateo de los datos antes de ingresarlos a la db(o para mostrarlos en el view) lo haria cuando se interactua con el objeto en los setters y getters del mismo.
Cosas extras no relacionados con la db pero si con los datos(como un envio de mail despues de grabar), no irian al modelo(antes lo ubicaba ahi). Y para evitar un controller muy extenso se usaria un Service Layer.

Doctrine
Con doctrine esto es muy facil. Al crear bien las entidades y las relaciones se puede manejar todos los objetos de una manera muy simple y facil. Si queres aumentar el rendimiento en algunas cosas se utilizaria DQL. Pero practicamente una vez que esta todo bien armado, es parecido a Zend_Db. Siempre se traen y se graban objetos.

Me fue muy dificil acostumbrarme. La nueva forma de manejarse es siempre con objetos, y no con datos agrupados. Al principio queria hacer todo con DQL(o con Zend_Db_Select) y traer solo arrays con datos(que es la manera con la que venia acostumbrado a hacerlo), pero era un codigo muy desastroso xD.

Me es todavia un poco dificil de aceptar el hecho de hacer varias consultas a la Db y de traer varios datos en vez de los que necesito. Esta claro que hay cierta perdida de rendimiento al utilizar todo en objetos, aunque a decir verdad queda todo mucho mejor estructurado y mas facil de entender. Asi que finalizando a todo esto pregunto y no molesto mas, realmente es mucha la perdida de rendimiento al trabajar todo con objetos?? o es relativamente bajo?.

Estaria bueno tambien que comenten como se manejan ustedes, mas aun los experimentados, que es lo que utilizan, de que forma, etc, asi aprendemos todos

Tambien acepto criticas constructivas

Gracias

[pablofmorales]

La verdad es que no use mucho doctrine con ZF, lo tuve que tocar en un proyecto en uso y crear algun adapter para el Zend_Auth, pero no mucho mas, (cuenta pendiente).

Con el tema de los modelos en el quickstarts no me gusto demasiados archviso al dope, no aportaba nada interesante, asi que continue creando los modelos de forma simple

Código PHP:

class Application_Model_News extends Zend_Db_Table {
   protected $_primary = 'id';
   protected $_name = 'news';
 
}
 

Y listo, despues metodos para manipular la tabla, pero solo un archivo por cada tabla, me parece lo mas prolijo.

[masterpuppet]

@pablofmorales, a mi no me parece algo inútil separar el modelo de la persistencia, mas bien todo lo contrario, y creo que es acertado por parte de Zend fomentar esta practica desde los primeros pasos con el FW y si yo no recuerdo mal, en el incubator de Zend se encuentra el auth adapter para Doctrine.

@RatoN7, de Zend_Db ni opino, no me agrada el componente y hace mucho que no lo utilizo, y con respecto a Doctrine te dejo un par de comentarios:

La nueva forma de manejarse es siempre con objetos, y no con datos agrupados. Al principio queria hacer todo con DQL(o con Zend_Db_Select) y traer solo arrays con datos(que es la manera con la que venia acostumbrado a hacerlo), pero era un codigo muy desastroso xD.

No siempre es bueno cargar objetos, si es para mostrar datos únicamente y no interviene lógica alguna, es mejor hydratar array's y por lo general es necesario el DQL para evitar el exceso de queries.
Algo que no comprendo es porque generar DQL te hizo el código "desastroso", en D1 el DQL va en cada Table y en D2 en los Repositories, me parece algo bastante ordenado.

Me es todavia un poco dificil de aceptar el hecho de hacer varias consultas a la Db y de traer varios datos en vez de los que necesito.

Algo parecido a lo anterior, no entiendo porque tienes esta idea, no es obligatorio ni aconsejable traerte datos que no necesitas, para esto esta el DQL, para hacer el hydrate de lo que necesites.

perdida de rendimiento al trabajar todo con objetos?? o es relativamente bajo?.

Se presupone al utilizar Doctrine que estas trabajando con un domain model complejo, lo que hace aceptable la perdida de rendimiento en favor de toda la ganancia que te da el ORM.

Saludos.

[pablofmorales]

Iniciado por masterpuppet

@pablofmorales, a mi no me parece algo inútil separar el modelo de la persistencia, mas bien todo lo contrario, y creo que es acertado por parte de Zend fomentar esta practica desde los primeros pasos con el FW y si yo no recuerdo mal, en el incubator de Zend se encuentra el auth adapter para Doctrine.

Hold on!!


Donde puse que es inutil?, tenes que tener cuidado con las citas y las interpretaciones, despues estas cosas confunden a los que recien empiezan con Zf.

Yo lo que dije fue que para mi y entendelo como, hace 3 anios que laburaba con ZF de esta manera, y venir y crear 3 archivos mas era inecesario, ya que no era un ORM, y en mi caso prefiero las cosas mas simple, ahi a decir que es inutil, ya es todo un mundo. No tengo idea si es util o no. Para mi cada cosa que hago tiene que tener ciertas caracteristicas, Simple, Util, Prolijo y en lo posible la mejor solucion para resolver el problema, en este caso era usar un ORM, lo unico que a mi entender aportaba algo interesante y no esto que agregaba mas capas, y la performance no variaba, pero se agregaban mas archivos, perdiendo la simplicidad de los modelos como veniamos trabajando hasta ahora, pero nunca dije Inutil.

[masterpuppet]

En que momento he dicho que esas son tus palabras ?, es mi interpretación de tu comentario, mas nada, con respecto a tener cuidado, estamos de acuerdo, y por eso mi comentario, para mi esto(y ahora si te cito)

Con el tema de los modelos en el quickstarts no me gusto demasiados archviso al dope, no aportaba nada interesante, asi que continue creando los modelos de forma simple

le da la idea al que empieza con Zend, que tantos ficheros son una perdida de tiempo, cuando en realidad no lo es.

@RatoN7, perdon por el offtopic

[pablofmorales]

Iniciado por masterpuppet

En que momento he dicho que esas son tus palabras ?, es mi interpretación de tu comentario, mas nada, con respecto a tener cuidado, estamos de acuerdo, y por eso mi comentario

De momento que refutas mis respuesta con el comentario "yo no creo que sea inutil..." estas dando a entender que yo dije que fuera inutil, por eso te corrijo.

Con respecto a

para mi esto(y ahora si te cito) le da la idea al que empieza con Zend, que tantos ficheros son una perdida de tiempo, cuando en realidad no lo es.

@RatoN7, perdon por el offtopic

Ok explica porque no lo es si te parece bien.

[_ssx]

Pablo creo que tu comentario sin querer entre lineas pareciera que se te hace inutil la separación del DbTable + Model, yo tambien lei lo mismo.

[RatoN7]

masterpuppet, no hay problema del "offtopic".
Sobre el tu post me aclaraste algo, pense que lo "correcto" o "standard" es trabajar con objetos hasta en las vistas. Y bueno lo del codigo "desastroso" nose porque lo puse xD, aunque se me hace que es mas ordenado con objetos, pero ahora dudo.

pablofmorales, una consulta. Alguna vez has usado las relaciones con Zend_Db_Table? El otro dia lo vi pero todavia no me puse a hacerlo andar y queria saber que tal es.

Esta bueno que cada uno de su opinion. Lo que si no lo lleven a una discusion de opiniones personales sino de ventajas de uso. Asi como Doctrine y Zend_Db son diferentes y cada uno tiene sus caracteristicas(ventajas y desventajas), tambien lo tiene usar Zend_Db con 1 o 3 archivos.

Me interesan sus opiniones, se que ambos tienen mas kilometros con Zend que yo.

Gracias

[pablofmorales]

Iniciado por RatoN7

masterpuppet, no hay problema del "offtopic".
Sobre el tu post me aclaraste algo, pense que lo "correcto" o "standard" es trabajar con objetos hasta en las vistas. Y bueno lo del codigo "desastroso" nose porque lo puse xD, aunque se me hace que es mas ordenado con objetos, pero ahora dudo.

pablofmorales, una consulta. Alguna vez has usado las relaciones con Zend_Db_Table? El otro dia lo vi pero todavia no me puse a hacerlo andar y queria saber que tal es.

Esta bueno que cada uno de su opinion. Lo que si no lo lleven a una discusion de opiniones personales sino de ventajas de uso. Asi como Doctrine y Zend_Db son diferentes y cada uno tiene sus caracteristicas(ventajas y desventajas), tambien lo tiene usar Zend_Db con 1 o 3 archivos.

Me interesan sus opiniones, se que ambos tienen mas kilometros con Zend que yo.

Gracias

Si claro que lo use, pero para lo que lo queria no andaba, tenia que usar un ORM, asi que deserte de usarlo,por lo mismo que no uso los Data Mapper, pero creo que si queres hacer bien las cosas deberias o usar un ORM como doctrine, o usar el Zend_Db_Table solo, por lo menos para entender bien como funciona, pero yo soy medio vago y no me gusta crear archivos solo por agregar mas capas. Preo seguramente masterpupper piense diferente, aca es cuestion de gustos y ZF te permite ser flexible.


@_ssx es que dije eso, a mi se me hace inutil, pero no dije que fuera inutil, es tan sutil la diferencia? yo no dije que esta mal, o que es inecesario, yo dije que a mi no me gusta, a mi no me parece necesario para lo que lo uso, me parece que tiene mucho mas sentido usar un ORM, que agregarle mas capas al modelo. Pero sobre gustos...

Acabo de revisar y cuando uso Zend_Tools, y pongo create model, solo me crea un archivo. Creo que el quickstar podria ser mas simple que lo que tenemos.

[teloxzak]

Que tal a todos señores con todo respeto discuten cosas triviales, que si esto y aquellos es mejor, y que si muchos o pocos archivos, creo que lo adecuado es contribuir de verdad, propongo conclusiones basadas en código y estadísticas de rendimiento y mejores prácticas de desarrollo, y así pueden ayudar a la comunidad y a los que nos estamos enseñando. Saludos