Pros y los contras de la utilización del patrón DAO [cerrado]

Question

Como menciono en el título, estoy interesado en saber lo que (ya que los desarrolladores experimentados) piensa en el uso del patrón DAO, específicamente dentro de una aplicación web. ¿Qué ventajas tiene que encontraste y qué consecuencias de su uso se ha disgustado?

Answer 1

Los problemas con DAOs que he visto es que se suelen manejar objetos llenos todo el tiempo. Esto crea sobrecarga completamente innecesario que no existiría con consultas simples. Por ejemplo, si un menú desplegable se va a crear fuera de los datos de referencia de base de datos, un usuario DAO puede decir simplemente: "Tráeme la colección de objetos de esta tabla en la que y ordenados por z". A continuación, los datos se utiliza en el menú desplegable, pero normalmente sólo por una combinación de clave / valor, haciendo caso omiso de todo lo demás en los objetos (datos creados, último usuario que lo puso al día, si es o no es activo, etc) que se recupera y se asigna . Incluso si este masaje se utiliza cerca de la llamada DAO y los objetos no se almacenan a medida que se recuperan (que por lo general no es el caso, por desgracia, los objetos son a menudo envueltos en corriente alterna: forEach (JSP) y repiten a lo largo de producir un menú desplegable ), todavía crea la base de datos que no sean necesarios y la sobrecarga de la red, por no mencionar el aumento temporal de la memoria para almacenar estos objetos.

Ahora, esto no quiere decir que un DAO no puede ser diseñado para recuperar un mapa de datos de referencia - que sin duda puede. Pero por lo general se usan para el mapeo de objetos completo, que no es lo que se necesita todo el tiempo. Es una fuerza al guardar, pero una debilidad, la OMI, al recuperar los datos - Seguro, se obtiene toda ella - pero a menudo no es necesario que todos, y sólo los desechos de memoria, ancho de banda y el tiempo

.

Answer 2

NOTA: es posible encontrar otros defectos, pero aquí hay una lista rápida de mi experiencia

PROS:

• Común exige para recuperar objetos.
• Una vez que tenga el general de crear / leer / actualizar / borrar de referencia de flujo, la disposición general se puede repetir para otras DAOs.
• También se consolida en la parte específica persistencia de su código puede ir. Se separa la lógica de negocio de otros componentes de su código.

CONS:

• No es lo más flexibles nunca.
• Si desea perezoso carga algunos objetos secundarios, entonces van a tener que o bien se entremezclan los DAOs con otras capas o tomar precauciones a la hora de intentar recuperar los objetos perezosos.
• Si escribir a mano los DAOs, a continuación, el código puede llegar a ser tedioso y repetitivo.

Answer 3

Beneficios del uso de patrón de diseño DAO

DAO o de acceso a datos de objetos de patrón de diseño es un buen ejemplo de la abstracción y la encapsulación de principios orientados a objetos. Se separa la lógica de persistencia es una capa separada llamada capa de acceso de datos que permite la aplicación de reaccionar de forma segura a cambiar en el mecanismo de persistencia. Por ejemplo, si usted cambia de mecanismo de persistencia basada en archivos de base de datos, los cambios se limita a la capa de acceso de datos y no tendrá impacto en la capa de servicio o de objetos de dominio. Objeto de Acceso a datos o patrón DAO es bastante estándar en la aplicación Java serlo núcleo de Java, la aplicación web o de aplicaciones empresariales. A continuación se presentan par de más beneficios de utilizar el patrón DAO en la aplicación Java:

1. patrón de diseño DAO también mantiene el acoplamiento de baja entre diferentes partes de una aplicación. Mediante el uso de patrón de diseño DAO Ver su capa es completamente independiente de la capa DAO y única capa de servicios tiene la dependencia en él que también se resumieron mediante el uso de la interfaz DAO.

2. patrón de diseño DAO permite prueba unitaria para correr más rápido, ya que permite crear Mock y evitar la conexión a la base de datos para ejecutar las pruebas. Mejora la prueba porque es fácil escribir prueba con objetos Mock, en lugar de una prueba de integración con la base de datos. En el caso de cualquier problema, mientras se ejecuta la prueba de la unidad, sólo tiene que comprobar el código y no la base de datos. También escudos con problemas de conectividad de base de datos y el medio ambiente.

3. Desde patrón DAO se basa en la interfaz, sino que también promueve orientado a objetos principio de diseño "de programación para la interfaz de la aplicación", que se traduce en código flexible y de calidad.

Answer 4

Las fuerzas del patrón DAO son que le permiten crear una buena capa de abstracción del sistema de almacenamiento real. Proporcionan una vista orientada a objetos más de la capa de persistencia y una separación limpia entre el dominio y el código que realmente realizar el acceso de datos (JDBC recta, frameworks de persistencia, ORM o incluso JPA).

Si tuviera que citar una debilidad, bueno, yo diría que es otra capa ... Pero supongo que este es el precio a pagar para no atar su código a la API de persistencia subyacente.

Answer 5

Hemos visto algún beneficio real en la introducción de un patrón DAO en nuestra aplicación. Esto debido principalmente a la clara separación entre la interfaz de base de datos y la aplicación. Hemos observado los siguientes beneficios:

• abstracción para la aplicación de acceso base de datos real separa la estrategia de acceso a los datos y la lógica de usuario. Esto nos ha permitido elegir un corto plazo (primavera Plantilla JDBC) estrategia de implementación para la fase inicial del proyecto con la opción de pasar a iBatis o hibernación en una fecha posterior. (Una elección que no están en condiciones de hacer en este momento.)
• La separación presenta ventajas significativas en la capacidad de prueba de que toda la implementación de acceso a datos puede ser burlado a cabo en la unidad de pruebas. (Este es probablemente el mayor beneficio)
• Combinando esto con la primavera nos permite inyectar cualquier aplicación DB en el sistema que elegimos (aunque esto posiblemente dice más de DI que el patrón DAO).

Una cuestión que nos encontramos, y esto puede ser debido a la falta de claridad del diseño de nuestra parte es la "inclinación" de reutilizar los objetos de valor Los datos publicados fuera de la base de datos como de transferencia de objetos entre las capas de abstracción posteriores en el arquitectura. Nuestra solución después de algo de dolor era tener un objeto de valor por capa (es decir, para no volver a utilizar el objetos de valor de base de datos en capas de arquitectura posteriores).

Answer 6

PRO

• único punto de definición para mesa DB - Object asignación de atributos
• posibilidad transparente para las implementaciones de DAO para otros tipos de almacenamiento
• desarrollar un patrón de interfaz de toda la continuación de DAO
• el desarrollo de una clase de prueba JUnit más o menos estándar para los resultados de DAO en una mejor cobertura de la prueba
• control total sobre aspectos específicos
• ninguna pérdida de rendimiento debido a una solución excesivamente genérica

CON

• menos "atractivo" de utilizar el último marco
• desarrolladores no llegan a inventar sus propias ruedas (podría ser un PRO: -))

Al igual que con la mayoría de los patrones de desarrollo, utilizando DAO de toma algún tiempo para acostumbrarse. Con la experiencia viene de los beneficios de un código más robusto y desarrolladores que saben por qué las cosas funcionan, no sólo que parece. Este último punto es la mayor ventaja para mí.

advertencia, dependiendo de su situación utilizando un framework de persistencia podría ser una buena alternativa a la codificación de su propio DAO.

Answer 7

¿Qué alternativa está considerando?

Parece bastante obvio que la colocación de la responsabilidad por la persistencia en otro lugar que la capa de presentación suele ser bueno, sólo de los argumentos de la claridad de la responsabilidad y la reutilización. Instintivamente a dar un enfoque de tres capas: presentación, el servicio, la persistencia. Confieso haber sido hacerlo de esta manera durante tanto tiempo que no puedo aduce evidencia de dolor sufrido por no hacerlo de esa manera. A mí me parece "obvio" que tiene una sola capa, que comprende el mecanismo de persistencia debe simplificar las pruebas, la facilidad de mantenimiento y dar una buena separación de preocupaciones.

Así que deja la cuestión de exactamente cómo hacer la capa de persistencia. Mi suposición por defecto sería el uso de la APP (o marcos similares). Hago ver esto como un sofisticado ejemplo de DAO.

Así que veo dos costos de DAO. Lo primero que necesita para invertir en su estructura del programa, su diseño. Para los casos triviales esto puede sentirse como un exceso. En segundo lugar, si se utiliza un marco que implementa DAO para usted hay una curva de aprendizaje. En comparación con sólo escribir el código JDBC directamente esta es otra inversión.

Answer 8

Pro: la separación abstracta
. En contra: código repetitivo (gracias a Dios por código generadores / plantillas y de ORM)

.