Busqueda cuando se trata de poo

[moron]

Consulta: Un temá de practica

Cuando tengo un sistema OO y persisto los datos en una BDR, la búsqueda como debo encararla?

Por ejemplo, necesito todos los libros del autor josé.

a: Voy a la base de datos y me traigo todos los libros con sus correspondientes autores y busco en todos los objetos libros cual de ellos tiene como autor a josé.

b: voy a la base de datos y busco mediante el motor de la base de datos a josé y genero los objetos libros en función de la relación josé -->libro

En cualquier caso, la consulta debería tener la estructura de un objeto libro, con un objeto autor con el atributo nombre = josé o no tiene que ser necesariamente así.

muchas gracias desde ya.

[emiliodeg]

la opcion b es la mejor
puedes tener una clase para las busquedas
con un metodo generico que haga una busqueda global sin filtros y luego otro metodo para agregar filtros en este caso librosPorAutor();

saludos

[moron]

Gracias.

saludos

[GatorV]

Concuerdo con emiliodeg, lo más eficiente y correcto es la opción B.

Saludos

[moron]

gracias GatorV

saludos

Iniciado por emiliodeg

la opcion b es la mejor
puedes tener una clase para las busquedas
con un metodo generico que haga una busqueda global sin filtros y luego otro metodo para agregar filtros en este caso librosPorAutor();

saludos

en cuanto a la mejor práctica, para cualquiera de los casos debo regenerar los objetos en función del resultado o mandar los registros a una clase vista que muestra los registros en pantalla. ?

actualmente tengo un conversor bdrObj que en funcion del resultado va generando una lista de objetos y luego le paso el objeto o lista de objetos a la vista.

[GatorV]

Pues lo ideal es que tu clase superior sea abstracta en ese aspecto y te regrese el objeto generico que tu le pidas. Por eso lo que te decia emiliodg de usar librosPorAutor, es decir que esperas obtener un arreglo de libros discriminando por autor.

Saludos

[moron]

es decir, la clase abstracta tiene métodos a implementar que me traerían un array de resultados, luego genero objetos o estoy demasiado obsesivo con crear objetos?

en realidad estoy tratando de implementar algo funcional, ya que la consulta es un tanto complicada. Tengo libros y la busqueda puede ser por autores (que estan en tablas relaciondas ) o por editores, temas, y un largo etc, y no se por que lado va a entrar a buscar el cliente. El tema de la busqueda ordenada por autores es solo un ejemplo, pero no se hasta el momento en que el cliente mete el criterio de busqueda como tengo que buscar.

hasta ahora lo vengo tratando con muchos switch + if's . Pero hay alguna opción mas elegante?

[enriqueplace]

Que tal Moron

Por ejemplo, necesito todos los libros del autor josé.

Como primera puntualización, si es un sistema OO deberían existir -por lo menos- los objetos involucrados en el problema, es decir, Autor y Libro.

Luego es un problema de paradigmas distintos, por un lado OO y por otro DER/MER, y cual es la filosofía, si aprovechamos el poder de la base de datos en detrimento de un sistema 100% POO o no nos importa la base de datos y queremos un sistema 100% POO consistente en todas sus capas.

a: Voy a la base de datos y me traigo todos los libros con sus correspondientes autores y busco en todos los objetos libros cual de ellos tiene como autor a josé.

Más que un tema de OO, es un tema de lógica en la resolución. Si quieres los libros del autor "José", en sí la navegación está definida: debes poder saber primero el nombre del autor para preguntar por sus libros.

Código PHP:

  
$autor = new Autor('José');

foreach($autor->getLibros() as $libro){
   echo $libro;
}  
   

Distinto sería si tienes un conjunto de libros y poder saber a quienes pertenecen (distinta navegación).

Código PHP:

  
$libros = Libro:getAll();

foreach($libros as $libro){

   if($libro->getAutor()->getNombre() == 'José'){
      echo $libro;
   }
}  
   

El punto está en "la letra del problema que quieres resolver", tratando de definir la navegación según tus necesidades y evitar al máximo tener "bidireccionalidad" entre los objetos: Libro -> Autor y Autor -> Libro (debes decidir por una sola).

b: voy a la base de datos y busco mediante el motor de la base de datos a josé y genero los objetos libros en función de la relación josé -->libro

Tu capa de persistencia debe poder obtener los datos de los libros filtrados por el autor, pero en algún momento tu dominio debería convertir los datos en objetos.






Lo ideal es ver todo el tema de diseño y relaciones a través de un diagrama UML.

[moron]

Hola Enrique, siempre tan dispuesto a dar una mano!

el tema es que la navegabilidad no la conozco.

imaginemos un formulario de búsqueda con los siguientes campos:

titulo: titulo del documento
and/ or autor: (autores seleccionados de una lista de personas se vinculan con tabla intermedia en la bd)
and/ or editor(idem autor):
and/ or año edicion
and/ or paisEdicion


el usuario puede seleccionar escribir un titulo para conocer sus atributos, como ser autores.
a bien puede buscar los libros de un determinado autor.
Me encuentro con el tema de navegabilidad en lo que respecta a OO y con problemas de join si hablamos de la bd, ya que hay que jugar con los inner outter, left etc, porque si busca un autor y no marcó un titulo y yo definí un inner join no va a mostrar los datos aunque existan autores.

[enriqueplace]

el tema es que la navegabilidad no la conozco.

En si me parece que sí, lo que tu tienes es un buscador de Libros con diversos filtros, no un buscador de autores, por lo tanto el Libro --conoce-> Autor

el usuario puede seleccionar escribir un titulo para conocer sus atributos, como ser autores.

Ok, un conjunto de filtros que se aplican en base a los atributos de un Libro.

Me encuentro con el tema de navegabilidad en lo que respecta a OO y con problemas de join si hablamos de la bd, ya que hay que jugar con los inner outter, left etc, porque si busca un autor y no marcó un titulo y yo definí un inner join no va a mostrar los datos aunque existan autores

Como te comentaba al principio, depende como lo quieras hacer, si lo haces 100% OO pero la solución dependen del funcionamiento de un Modelo Relacional (base de datos), tal vez te convenga hacerlo desde esa óptica.

Lo que puedes hacer es:

1. Capa de presentación, crear un formulario que obtiene todos los filtros
2. Estos datos pasan de la capa de Dominio a la capa de Persistencia, donde llegan los filtros y se genera la consulta dinámica (sql).
3. Con los datos obtenidos (array) la persistencia entrega al dominio los datos para que este construya una colección de objetos "Libro" y se la entregue a la capa de presentación.

Ten en cuenta que ya estás detectando un "foco de cambio" en el sistema, que son la creación de filtros nuevos que aún desconoces y que continuamente puede ser que se agreguen. Ahí tienes que aplicar el principio de diseño "Abierto / Cerrado" para poder "solo incorporando código nuevo" (sin modificar el código existente) obtener la extensión de la funcionalidad del buscador.

Básicamente debes abstrar en clases "Filtro" el algoritmo de búsqueda que decide si el objeto es "seleccionable" para obtener el resultado.

[moron]

Gracias Enrique, voy a investigar un poco lo de abierto / cerrado , se refiere a algún patrón en particular?

[enriqueplace]

Iniciado por moron

Gracias Enrique, voy a investigar un poco lo de abierto / cerrado , se refiere a algún patrón en particular?

Es un principio de diseño que la mayoría de los buenos diseños, como ser los Patrones de Diseño, lo cumplen.

[moron]

Muy agradecido Enrique. No se si es abusar demasiado ya, pero podrías darme un ejemplo sencillo en un par de lineas de codigo ,de lo que le llamas clase filtro.

yo abstraigo las conecciones en una clase "mysql" ahora el ir generando filtros por ejemplo con una clase filtro_autor y otra filtro_titulo me queda colgado como repartir y vincular responsabilidad (si es que entendí bien).

Estuve viendo lo de principios de diseño, me pareció muy bueno, aunque lo tengo que agarrar con mas tiempo.

saludos

[enriqueplace]

Iniciado por moron

Muy agradecido Enrique. No se si es abusar demasiado ya, pero podrías darme un ejemplo sencillo en un par de lineas de codigo ,de lo que le llamas clase filtro.

yo abstraigo las conecciones en una clase "mysql" ahora el ir generando filtros por ejemplo con una clase filtro_autor y otra filtro_titulo me queda colgado como repartir y vincular responsabilidad (si es que entendí bien).

Estuve viendo lo de principios de diseño, me pareció muy bueno, aunque lo tengo que agarrar con mas tiempo.

saludos

Lo que te pido a cambio es que hagas un diseño en UML de lo que tienes actualmente y/o cómo piensas abstraer el problema de tener filtros que irán cambiando.

Una vez que tengas el diagrama, lo subes al foro y con gusto discutimos a partir de él las correcciones que habrían que hacerle al diseño.

[moron]

Hola Enrique, no logro pegar el uml.asi que esto va a ser medio desprolijo:


clases:
libro: asociación de agregación con:
MaterialAdic(de esta Heredan: Mapa, Video).
Autor (Hereda de Personas)


Libro:
-titulo
-subtitulo
-contenido
-etc

MaterialAdic:
-cantidad
-tamaño
-color

Mapa (extends MaterialAdic)
-escala

Video (extends MaterialAdic)

Persona
-nombre
-apellido
-etc

Autor (extends persona)
-posicion



El tema de las responsabilidades en cuanto a las busquedas, ahi es donde hago agua

estoy armando una serie de clases de consulta, segun lo que he entendido de lo que fui leyendo:

ClassMySql
+ conectar
+ execute (query:string): array

abstractConsultas extends ClassMySql
# select($query:string):array

ClassLibrosFiltrados
+armarConsulta($_Post):string --->query
+ObtenerDatos($query:string): arrayDeObjetosLibro

ClassOtroFiltro ---> n clases que filtran diferentes cosas

[enriqueplace]

Entra a http://www.4shared.com, te creas una cuenta y subes el UML.

Luego con el link, lo agregas al foro.

[moron]

ahi va:


http://www.4shared.com/file/82979116...8/_2__uml.html

ahi subí un diseño que me parece que queda mejor. ud. dirá

[enriqueplace]

Comentarios varios:

1. Las clases debería ir siempre en singular: cambia Consultas por Consulta
2. Las clases deben iniciar siempre con la primer letra en mayúsculas y los métodos siempre inician con la primer letra en minúsculas.
3. Faltan los atributos en las clases
4. La clase Consultas no es un tipo de MySQL, no hay una relación de parentesco entre las clases, por consiguiente NUNCA debe haber herencia.
5. Falta en el diagrama la clase Usuario
6. No entiendo la relación entre la Interface y la clase Consultas
7. Cambia el nombre de interfaceInformate a InformateInterface
8. Lo que te sugiero es que ya empieces a separar el sistema en capas, esto te ordena y te ayuda a razonar el diseño de tu sistema (al pensar un tema por vez).

La verdad que veo bastante entreverado el diseño. Hablamos de que era evidente la existencia de clases como Libro y Autor, y no las veo.

Mi sugerencia es que hagas un simple que esté en 3 capas y luego resuelvas bien el tema de las clases del dominio y de la persistencia. Posteriormente lo evoluciones para resolver el segundo problema, que es el tema de los filtros.

Pero si haces todo junto, no vas a llegar a ningún lado.

Por ejemplo

1. Capa Presentación: BusquedaPresentacion.php
2. Dominio: Busqueda.php, Libro.php y Autor.php
3. Persistencia: BaseDeDatos.php, LibroPersistencia.php, AutorPersistencia.php

Una forma de resolver las búsquedas es pedir todo a la clase Libro y esta sabe sus relaciones con los autores.

Luego lo puedes ir evolucionado paulatinamente.

[moron]

Gracias por la respuesta, en realidad quería armar una capa de consultas independiente del modelo (no se si sea lo optimo)

te paso el modelo de clases real, ya que lo que te pasé anteriormente fue algo ilustrativo con el fin de que se entienda lo que quería hacer (aunque haya hecho lo contrario jeje).

también adjunto un diagrama de secuancia con la forma en que hago un ingreso de un titulo (titulo = libro = documento)

http://www.4shared.com/file/83255349...el_modelo.html

pd: Das un curso sobre esto? . cuando, donde, cuanto.

[enriqueplace]

Estimado, pregunta: ¿el sistema es tan grande como para hacer un diseño con tantas clases? Habría que ver de analizarlo si se puede simplificar. Por lo pronto con la lista de correcciones que te pasé ya puedes ir haciendo algo.

Sobre mis cursos, tienes toda la información en mi firma, cualquier cosa me envías un mensaje privado y me haces las consultas que necesites.

[moron]

El sistema es bastante grande si. voy a ir haciendo las modificaciones que me sugeriste y ver de acotar lo que pueda.

Otra cosa que me traba es el tema de los objetos en cliente y servidor. Intento respetar el diseño en ambas esferas, hay alguna especificacion para esto?.


y con eso basta por un tiempo. Ya siento que estoy abusando. :)


saludos y muchicimas gracias

[sergabrod]

Hola, coincido con lo que dice Enrique, a veces tampoco hay que enceguecerse con resolver todo OOP, si tu sistema realmente lo amerita perfecto, te puedo apuntar algo respecto a switch y ifs, si tu sistema abusa de ellos es porque realmente no es 100% o quizá ni siquiera lo sea 50%, si esto ocurre tu sistema presenta un acoplamiento importante y deberías estar usando en ese caso el polimorfismo.

En tu problema, donde podes tener diferentes combinaciones de busqueda y no sabes de antemano cuantas combinaciones vas a tener, un diseño elegante sería usar el patrón Decorator, deberias tener una clase abstracta BusquedaDecorator y sus clases que heredan BusquedaAutor, BusquedaEdicion, BusquedaTitulo, etc. y asi una clase por cada atributo sobre el que quieras realizar la búsqueda, esto permite combinar o "decorar" tu búsqueda por todas las combinaciones que necesites, de esta manera agregar o quitar un criterio de busqueda sería transparente para tu diseño.

Saludos.

http://es.wikipedia.org/wiki/Decorat...de_dise%C3%B1o)

Sergio Gabriel Rodriguez

Perdón, cuando escribí "no es 100% o quizá ni siquiera lo sea 50%" me refería a 100% OOP.

Saludos!.

Sergio Gabriel Rodriguez