Necesito alguna aclaración con Patterns (DAO x Gateway)

Question

Mis colegas y yo comenzamos esta discusión temprano esta mañana, y nuestras opiniones comenzaron a chocar un poco, así que decidí obtener un consejo imparcial aquí.

Uno de mis colegas reconoce que el DAO debe devolver un objeto (beans poblados). Creo que está completamente bien cuando devuelves un conjunto de registros con solo una línea, pero piensas que es excesivo si tienes que devolver 10 líneas y crear 10 objetos separados.

Yo veo que la diferencia entre el patrón DAO y Gateway es que el patrón de puerta de enlace le permitirá devolver un conjunto de registros a su clase de negocio, que tratará los datos del conjunto de registros y hará lo que sea necesario.

Mis preguntas aquí son:

1. Qué suposiciones son correctas?
2. Cuál debería ser el tipo de retorno será por un DAO (es decir getContact() - para un registro)
3. En caso getContacts() (para múltiples registros) incluso estar en el DAO, si es así, ¿qué es returntype?

Parece que estamos teniendo algún tipo de confusión sobre DAO y Gateway Patterns. ¿Deberían usarse juntos?

Gracias de antemano

Answer 1

El patrón de puerta de enlace se refiere a proporcionar un único punto de acceso para un sistema o subsistema. El patrón DAO es un tipo específico de puerta de enlace: proporciona el único medio para obtener un tipo particular de datos del almacén de datos.

Voy a responder a las preguntas directamente, aquí y ampliar las respuestas a continuación.

1. Qué suposiciones son correctas. El patten DAO se ocupa de ocultar los detalles de captar entidades y consultas sobre entidades. Devolver un conjunto de registros que esté directamente relacionado con el mecanismo de persistencia generalmente no es una buena idea ya que rompe la abstracción. Al mantener el almacenamiento independiente de DAO, las pruebas son mucho más sencillas; es posible simular una interfaz DAO utilizando, por ejemplo, una implementación simple en memoria basada en datos de prueba almacenados en colecciones.

2. ¿Qué debe ser el tipo de retorno para un DAO (es decir getContact() - para un registro) El tipo de retorno debe ser Contact frijol. A medida que agrega atributos al contacto, solo la clase de contacto debe cambiar: la interfaz DAO permanece igual.

3. ¿Debería getContacts() (para múltiples registros) estar incluso en el DAO? Si es así, ¿qué es el retornado? Puse métodos de consulta junto con otros métodos DAO - Realmente no veo una distinción. Se pueden devolver múltiples contactos como una Lista o Colección apropiada de Contact frijoles.

El debate sobre la devolución de objetos o solo los valores necesarios es uno de diseño y rendimiento extensibles. La opción predeterminada debería ser devolver Beans. La mayoría de los mapeadores ORM e incluso las capas de acceso JDBC hacen que la creación de objetos sea relativamente liviana (las JVM modernas pueden crear un nuevo objeto en menos de 10 instrucciones de CPU) y es la mejor opción de diseño y evolucionará fácilmente.

La devolución de resultados no objeto, como una lista de ID de cliente, es una posibilidad, pero debe tomarse cuando haya pruebas claras de que es necesario. El rendimiento suele ser el factor motivador, por lo que el diseño debe respaldarse con pruebas de perfil. De lo contrario, es probable que sacrifique un buen diseño a favor de una optimización prematura. Ampliar un diseño que devuelve datos no objeto puede ser difícil; digamos que ahora quiere devolver la identificación del cliente y la fecha del último pedido. Si está devolviendo datos como filas y tipos primitivos, la forma del tipo de retorno va a cambiar, lo que normalmente requiere que cambien los métodos en la interfaz DAO y la implementación, y todos los clientes que los utilizan. Con un bean, los datos relacionados pueden obtenerse sin cambiar la forma de los datos, suponiendo que los datos relacionados están disponibles a partir del bean que ya se está devolviendo.

Los granos no necesitan estar completamente rellenos. Los mapeadores de ORM tienden a buscar de forma perezosa objetos y colecciones relacionados, por lo que se toma el rendimiento por lo que se recupera.

En resumen, si bien es posible tener una combinación de métodos que devuelven resultados de frijol y sin frijol, me alejaría de los resultados que no son de frijol a menos que haya una razón convincente para hacerlo. Y hágalo consciente de los problemas de mantenimiento que esto puede causar.

Answer 2

Este es un patrón de diseño, y lo más importante es ser constante. En mi opinión, los DAO deben devolver los objetos comerciales y no devolver los conjuntos de registros a menos que exista una razón comercial MUY buena para evitar hacerlo. Si una función potencialmente devuelve más de un objeto, debe devolver una Colección de objetos. Mejor aún, use un framework como JPA o hibernate para que pueda dejar que un framework se encargue de la persistencia.