Me gustaría conocer los patrones de diseño que se pueden aplicar en la implementación de Java EE 6.Java EE 6 Patrones de diseño
Do APP eliminar el uso de DAO?
Proporcione otros patrones que puedan aprenderse.
Si usa Java EE 6 (no Java EE 5), algunos de los patrones J2EE técnicos ya no son necesarios para la tarea que se utilizan en J2EE.
Por ejemplo, use la inyección en lugar de ServiceLocator.
patrones @see http://pawelstawicki.blogspot.com/2010/07/review-real-world-java-ee-patterns.html
GOF siendo necesarios, porque no son (sólo) en relación con Java EE.
En general: los patrones tienen una intención: quieren producir una solución/mejor práctica para un problema, con un conjunto de funcionalidades determinadas que es proporcionado por el entorno (en su caso: es Java, Java EE 6, ...)
Hay una buena referencia aquí: http://martinfowler.com/eaaCatalog/
También aquí: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
Además, la APP no elimina necesariamente la necesidad de una capa DAO. En su lugar, la capa DAO seguirá generando las consultas JPA, probablemente dentro de los métodos del buscador, y devolverá las entidades que devolvieron esas consultas.
pudiera eliminar la capa DAO, y en lugar de golpear las entidades JPA directamente dentro de su capa de negocio, pero personalmente aún así como para mantener una persistencia separado (DAO) y la capa de negocio, sobre todo en aquellos casos en los que acaban de tener que mezclar hasta un poco de JPA con JDBC simple, etc.
Hay un gran resumen del debate here. La mejor respuesta es que depende. Si su aplicación es compleja, y puede estar accediendo a JDBC directamente en algunos casos (porque las herramientas JPA y ORM no son la respuesta a todo, y son muy malas en algunas cosas), o si necesita extraer datos de fuentes que simplemente no usan No funciona bien con ORM, de todos modos necesitará una capa DAO, así que en mi opinión, prefiero ser consistente y usar una capa DAO para todo. Por lo general, no es tan complejo y aísla la lógica de su negocio de su lógica de persistencia, que creo que es algo bueno. Pero, es una cuestión de preferencia personal, y si su aplicación es adecuadamente simple, es probable que sea excesiva.
Hay una buena recomendación de un patrón DAO genérico que se puede utilizar con JPA here. Esto le permite los beneficios de un DAO, ya que siempre puede anular esto para un DAO específico, al mismo tiempo que simplifica las interacciones de las bases de datos más estándar y típicas.
¿Cómo debemos diseñar JPA y DAO juntos? ¿Puedes dar más detalles sobre esto? – peterwkc
Estoy de acuerdo con usted. Por lo tanto, me gustaría preguntar qué patrones todavía se requieren. – peterwkc
@peterwkc: vea mi respuesta extendida, espero que la regla general lo guíe para encontrar los patrones "en desuso". – Ralph
Perdón por hacer una pregunta tan estúpida. Dado que el patrón está destinado a resolver el problema a menos que el problema aún exista, debemos aplicar un patrón específico para resolver el problema. – peterwkc