Estoy a punto de implementar un patrón de diseño DAO en mi proyecto y entiendo que este es el más comúnmente utilizado para comunicarse con la base de datos.
Pero como suele haber una interfaz y unaNo puedo ayudar a pensar que esto también se puede usar para HTTP. Es decir, tiene una implementación DAO para CRUD contra la base de datos y otra implementación DAO para acceder a una API de CRUD. Pero si también se usa así, entonces, ¿qué? ¿Es la forma común de resolver el problema que podría no tener permisos de eliminación en la API?
¿Es correcto o por qué necesitaría una interfaz para esto? ¿O es solo para permitirme cambiar fácilmente la implementación de la base de datos?
Respuestas
1 para la respuesta № 1El patrón DAO se utiliza generalmente para desacoplardiferentes formas de representación de datos; por ejemplo, separe un esquema de base de datos de la lógica de la aplicación Java. Las interfaces (en el sentido que creo que están discutiendo) se usan normalmente para desacoplar la implementación de la lógica Java de su implementación. Estas dos formas de desacoplamiento son completamente diferentes, y no hay razón para no usar ambas juntas, si eso hace que el diseño sea más mantenible o expresivo. Incluso si el código Java está destinado a ser de propósito general (por ejemplo, en alguna biblioteca reutilizable) , entonces no creo que sea obligatorio especificar su comportamiento por medio de interfaces, aunque hay diferentes puntos de vista sobre este punto.
En cuanto a su pregunta específica: Si tiene métodos Java que operan con datos, y esas operaciones pueden fallar, entonces convencionalmente usted lanzaría una excepción. Si está utilizando DAOs y parte de su lógica de Java está altamente desacoplada de la implementación del almacenamiento de datos, entonces esa lógica podría no reconocer el "acceso denegado" como un concepto significativo. En tales casos, también tiene que desacoplar las excepciones y hacer que su lógica DAO lance una excepción general de "actualización fallida". Esa excepción puede llevar la excepción original ("acceso denegado") que vino de la implementación de almacenamiento específica hasta su llamador, que puede o no ser capaz de darle algún sentido. Uno de los peligros de un desacoplamiento extenso es que el manejo de errores se vuelve cada vez más inespecífico cuanto más se aleja del origen del error.