Saltar al contenido

Estructura del paquete DAO

Nuestro equipo especializado pasados muchos días de trabajo y recopilación de de información, hemos dado con los datos necesarios, nuestro deseo es que todo este artículo sea de utilidad para tu plan.

Solución:

Al diseñar una aplicación no hay estándar forma de estructurar en paquetes, la experiencia es lo que suele ayudar a cada uno a decidir cuáles son los nombres apropiados para nuestros paquetes.

Acerca de empaquetar implementaciones de sus interfaces en el mismo paquete o en uno diferente, solo piense en cómo está estructurado Java: por lo general, una clase de implementación se empaqueta en el mismo paquete que su interfaz, pero no siempre.

Si estuviera a punto de tener varias implementaciones de los mismos DAO, tendría sentido tenerlos estructurados en .jdbc, .jpa o .jdo subpaquetes. Si solo va a tener una implementación, las dos opciones que enumera tienen sentido de alguna manera (el mismo paquete o un .impl subpaquete).

Con respecto al exceso de ingeniería, le recomendaría este artículo. Aunque solo tendrá una implementación de sus DAO, tendría sentido definirlos como una interfaz e implementación, ya que eso lo ayudará en un futuro potencial a reescribir sus DAO para otros marcos mientras el código que hace uso de ellos se mantiene sin cambios.

Al final depende de usted (o de usted y sus compañeros) llegar a un consenso y tomar la decisión que tenga más sentido en su caso específico.

EDITAR

Una aplicación generalmente tiene una implementación por interfaz DAO y eso no es un exceso de ingeniería en absoluto, simplemente no tiene sentido tener la misma interfaz DAO implementada para JPA y para JDO. Algunos de los propósitos de usar el patrón de interfaz/implementación es facilitar la refactorización, las pruebas por medio de objetos simulados, etc.

PD: Por lo general, confío en JDepend para distribuir mis clases de aplicaciones en paquetes evitando los ciclos lo más que puedo.

no creo que tampoco lo sea mejor, pero en este caso prefiero la primera alternativa. Estaría en consonancia con tener ArrayList, LinkedListetc. , en el mismo paquete que List.

Cuando se utilizan marcos adicionales, como hibernate Prefiero la segunda opción con MyDao y HibernateDao como implementador.

Iría con su segunda opción (aunque ninguna es realmente mejor), porque puede ver inmediatamente en sus importaciones si se importa un impl y la refactorización sería más simple si desea mover su impl a otro proyecto.

Esto no es sobreingeniería. Las ventajas de usar DAO son múltiples:

  1. Mejora la calidad de su código al desvincular el acceso a la base de datos de otras consideraciones.
  2. Probar su código es más fácil y puede probarlo con un grano más fino.
  3. Si algún día descubre que Hibernate es en realidad mucho más fácil para usted, no afectará el resto de su código.

Tienes la opción de añadir valor a nuestro contenido informacional añadiendo tu experiencia en las acotaciones.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags : / /

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *