¿Qué patrón se ajusta entre una fachada y un DAO?

Question

Estoy en proceso de diseñar parte de la arquitectura de mi empresa para sus aplicaciones web Java EE. Tengo bastante claro los motivos para usar una fachada y uno o más DAO. El problema que tengo es este:

Habrá un poco de lógica que definitivamente pertenece al nivel de integración porque se trata de mantener el modelo de datos constante. Excepto que la lógica va más allá de simplemente mantener la integridad referencial y otras tareas de persistencia "en bruto" que serán manejadas por JPA e Hibernate. No clasifico esto como lógica comercial porque está separado de cualquier función comercial. Sin embargo, tengo entendido que un DAO solo debe implementar la lógica requerida para acceder y persistir objetos a la fuente de datos.

Mi conclusión es que necesito un patrón tipo 'objeto de negocio' que sea apropiado para el nivel de integración. Miré a mi alrededor y lo más parecido que he encontrado (aunque todavía no me parece bien) es el Sun Transfer Object Assembler pattern.

O hay una brecha en mi comprensión de Java EE o hay un patrón que cabrá.

Answer 1

tal vez un mediator es lo que quiere:

definir un objeto que encapsula cómo interactúan un conjunto de objetos. El mediador promueve el acoplamiento flexible evitando que los objetos se refieran entre sí de forma explícita, y le permite variar su interacción de forma independiente.

continuación, se puede utilizar un DaoMediator el fin de coordinar dos o más DAO s

Answer 2

Me parece que le puede faltar un controlador y, en consecuencia, puede necesitar el patrón MVC. El controlador cuidará de los DAO y presentará una vista coherente (no piense en términos de GUI, sino en una interfaz orientada al cliente). Cuando se realizan modificaciones a través de esta vista, el controlador coordina los cambios al modelo a través de DAO. Sospecho que los objetos de su fachada pueden ser la vista en este escenario.

Habiendo dicho esto, no me preocuparía demasiado demasiado sobre la identificación de patrones particulares. A menudo encuentra que teniendo en cuenta todos sus requisitos y separando las preocupaciones donde corresponda, que termine implementando un patrón particular y solo lo identifique como tal después del hecho.

Answer 3

Creo que es un patrón DataMapper (o adaptador) entre su DAL y su Business Layer, pero sin una comprensión más concreta, no podía estar seguro.

Answer 4

¿Ha considerado el uso de agregados de Domain Driven Design? Soy estudiante de DDD y parece que la lógica empresarial que intenta diseñar podría lograrse mediante modelos de dominio tipo POJO más ricos. Tendría que cada objeto de dominio fuera responsable de sus objetos agregados, y también incluyera cualquier lógica relacionada con ese concepto de negocio; Dicho esto, su capa de integración coordinaría esos objetos ricos pero se abstendría de tener una lógica real per se (es decir, varias lógicas condicionales).

¿Quizás el patrón que está tratando de encontrar es realmente un paso hacia objetos de dominio más ricos?

Answer 5

¿Qué está impulsando el requisito de coherencia entre los DAO? Si hay alguna suposición comercial que está dictando la relación.Por ejemplo, puede tener un tipo de factura que cuando es 'Capital', entonces tenemos que asegurarnos de que varios otros objetos estén en el estado correcto o tengan el conjunto correcto de valores. Esto definitivamente está fuera del ámbito de la capa de datos.

No trataría de encontrar el patrón perfecto para este caso. Sin embargo, necesitas algún tipo de clase de coordinación, un mediador o controlador de algún tipo.