Welches Muster passt zwischen einer Fassade und einem DAO?

Question

Ich bin gerade dabei, einen Teil meiner Unternehmensarchitektur für seine Java EE-Webanwendungen zu entwerfen. Ich bin mir ziemlich klar über die Gründe, eine Fassade und ein oder mehrere DAOs zu verwenden. Das Problem, das ich habe, ist das:

Es wird einige Logik geben, die definitiv in die Integrationsschicht gehört, weil es alles darum geht, das Datenmodell konsistent zu halten. Abgesehen davon, dass die Logik nicht nur die referenzielle Integrität und andere "rohe" Persistenzaufgaben beibehält, die von JPA und Hibernate gehandhabt werden. Ich kann dies nicht als Geschäftslogik einstufen, da es von jeder Geschäftsfunktion getrennt ist. Mein Verständnis ist jedoch, dass ein DAO nur die Logik implementieren sollte, die erforderlich ist, um Objekte auf die Datenquelle zuzugreifen und diese zu erhalten.

Meine Schlussfolgerung ist, dass ich ein "Geschäftsobjekt" ähnliches Muster brauche, das für die Integrationsschicht geeignet ist. Ich habe mich umgesehen und das nächste, was ich gefunden habe (aber immer noch nicht ganz richtig) ist die Sun Transfer Object Assembler pattern.

Entweder gibt es eine Lücke in meinem Verständnis von Java EE oder es gibt ein Muster da draußen, das passt.

Answer 1

vielleicht ein mediator ist, was Sie wollen:

ein Objekt definieren, das verkapselt, wie eine Reihe von Objekten interagieren. Mediator fördert lose Kopplung, indem er Objekte davon abhält, sich explizit aufeinander zu beziehen, und Sie können ihre Interaktion unabhängig voneinander variieren.

dann können Sie ein DaoMediator verwenden, um zwei oder mehr zu koordinieren DAO s

Answer 2

Es klingt für mich, als ob Sie einen Controller vermissen, und folglich das Muster MVC benötigen. Der Controller wird sich um die DAOs kümmern und eine konsistente Ansicht präsentieren (denke nicht an GUIs, sondern an eine Client-orientierte Schnittstelle). Wenn Änderungen über diese Ansicht vorgenommen werden, koordiniert der Controller die Änderungen am Modell über das DAO. Ich vermute, dass Ihre Fassadenobjekte die Ansicht in diesem Szenario sein können.

Nachdem ich dies gesagt habe, würde ich mir keine Sorgen zu viel über die Identifizierung bestimmter Muster. Sie finden oft, dass Sie alle Ihre Anforderungen berücksichtigen und gegebenenfalls Probleme trennen, dass Sie ein bestimmtes Muster implementieren und es erst im Nachhinein als solches identifizieren.

Answer 3

Ich denke, es ist ein DataMapper (oder Adapter) Muster zwischen Ihrem DAL und Ihrem Business Layer, aber ohne ein konkreteres Verständnis, ich konnte nicht sicher sein.

Answer 4

Haben Sie darüber nachgedacht Aggregate von Domain-Driven Design mit? Ich bin ein Student von DDD selbst und es scheint, dass die Geschäftslogik, die Sie versuchen zu entwerfen, durch reichere POJO-ähnliche Domänenmodelle erreicht werden könnte. Sie müssten jedes Domain-Objekt für seine Aggregatobjekte verantwortlich machen und auch jede Logik in Bezug auf dieses Geschäftskonzept enthalten. Das heißt, Ihre Integrationsschicht würde diese reichen Objekte koordinieren, würde jedoch von sich aus keine echte Logik als solche haben (d. h. mehrere bedingte Logik).

Vielleicht ist das Muster, das Sie suchen, tatsächlich ein Schritt in reichere Domänenobjekte?

Answer 5

Was treibt die Anforderung für Konsistenz zwischen den DAOs? Wenn es eine Geschäftsannahme gibt, die die Beziehung diktiert.Zum Beispiel könnten Sie einen Rechnungstyp haben, der, wenn es "Kapital" ist, dann sicherstellen muss, dass mehrere andere Objekte im richtigen Zustand sind oder die richtigen Werte haben. Dies ist definitiv außerhalb des Bereichs der Datenschicht.

Ich würde nicht versuchen, das perfekte Muster für diesen Fall zu finden. Du brauchst jedoch irgendeine Art von koordinierender Klasse, einen Vermittler oder Controller.