Uso de DAO con objetos compuestos

Estoy tratando de reescribir un montón de DAOs aquí es el escenario:Uso de DAO con objetos compuestos

única llanura JDBC (sin JPA, ORM en absoluto)
ninguna interfaz utiliza
un montón de cheques antes de insertar un objeto
Los objetos de negocio están estrechamente vinculados

Mi pregunta principal es: ¿Cómo PERSI st/recuperar un objeto comercial que se compone de varios otros objetos? p. ¿Conoce mi CustomerDAO la AddressDAO y recupera las direcciones de los csutomers desde allí?

Fuente

2012-09-09 er4z0r

echa un vistazo a [jcabi-jdbc] (http://www.jcabi.com/jcabi-jdbc), es un envoltorio liviano para JDBC (soy desarrollador) – yegor256

única llanura JDBC (sin JPA, ORM en absoluto) objetos de negocio están enlazados fuertemente

No sé por qué usted no desea utilizar la APP, mientras que usted quiere que sus objetos de negocio para ser vinculados, pero al menos debería usar la plantilla Spring JDBC que lo relevaría de algún código repetitivo.

En cuanto a las otras limitaciones, lo haría de la siguiente manera:

Me gustaría volver a utilizar las interfaces para definir los métodos DAO y ponerlas en práctica en una plantilla de Primavera JDBC respaldado DAOImpl. Use el DAO en todas partes e inyecte el DAOImpl.
Mis DAO serán simplemente mapeo uno a uno a las tablas subyacentes y cada DAO no sabría sobre la existencia de otros DAO.
Mi capa Manager tendrá toda la lógica comercial que ejecuta las comprobaciones de validación y prepara el conjunto de objetos que necesitan persistir, llama al DAO apropiado y al método apropiado (CREATE/UPDATE/DELETE) para conservar los objetos.
Nuevamente, la capa Manager seguirá la implementación basada en la interfaz y la capa de vista tendrá tipos de administrador inyectados con ManagerImpls.

Mis dos centavos!

Fuente

2012-09-09 13:03:52 Vikdor

¡Gracias! Pensé en JPA. Hasta el momento, el argumento opuesto fue que esta aplicación no está diseñada de ninguna manera y no estoy seguro de qué tan acertada funcionaría la JPA. (¡Esto ni siquiera se ejecuta en un servidor de aplicaciones!). Sin embargo, si obtengo los puntos correctos 2-4, esencialmente significaría que codifico mi propio entityManager, ¿verdad? – er4z0r

Correcto, su capa de administrador conocerá las asociaciones entre diferentes objetos de dominio (por ejemplo, Cliente, Dirección), etc. Si utilizó la especificación JPA para definir sus entidades y sus asociaciones y empleó un proveedor JPA (como Hibernate), lo haría se han ocupado de persistir en la jerarquía de objetos y su poder se concentraría en la traducción del objeto de transferencia de datos -> dominio. – Vikdor

Puede considerar el uso de JOOQ. No es JPA, pero puede usarse fácilmente como una solución alternativa. Es lo suficientemente ligero. También proporciona una herramienta de ingeniería inversa, donde crea sus entidades de base de datos como objetos DAO.

He incrustado JOOQ en una situación relevante, donde la aplicación fue diseñada de forma bastante precisa. No usé su funcionalidad DAO, en lugar de usarla como una capa superior para evitar jugar con JDBC Layer.

¡Salud!

Fuente

2012-09-09 13:51:26

Las entidades compuestas son una capa por encima de las DAO. Si desea eliminar TODO el acoplamiento, los objetos de dominio persistidos por DAO deben ser planos sin relaciones. Ver patrones Core J2EE CompositeEntity.

Además, es una buena idea no introducir el acoplamiento entre los DAO colocando buscadores para uno en el otro. P. ej .:

AddressDAO.findForCustomerId (id);

es inferior al uso de un tercer DAO para gestionar la relación. I.E:

CustomerAddressRelDAO.findAddressForCustomer (id);

Si usa una relación DAO, ni la dirección ni el cliente dependen de (o conocen) entre sí.

Fuente

2016-01-15 23:13:13 jcfolsom

Respuesta

Cuestiones relacionadas