Für mich hört sich das alles ein bisschen seltsam an. Was ich bis jetzt so gelesen habe, lässt darauf schließen, dass hier versucht wird ein DAO für alles zu basteln. Warum nicht für jede Domain ein eigenes DAO, sprich ein DAO für A und eins für B? Natürlich kann man alles in einen solchen “Manager” klatschen, aber was hat das für Vorteile? Keine, es verwischt nur Grenzen. Als Facade würde ich das noch verstehen, aber dann wären es immer noch unterschiedliche Domain-bezogene Implementierungen, die dahinter weggekapselt werden, sprich die jeweiligen DAOs. Und damit ist dann auch klar, dass A und B nur DTOs sind, also “dumme” Beans/POJOs, die passende DAOs benötigen
Im Grunde ist es doch so: Man hat irgendwelche Klassen, die man zur Repräsentation von Daten (z.B. Datensätze in einer Datenbank) und zur Verarbeitung dieser nutzen will, also DTOs. Damit man an solche Daten bzw. Instanzen solcher Klassen gelangt oder auch um Instanzen dieser zu verarbeiten, benötigt man irgend eine Schnittstelle, die z.B. mit der Datenbank kommunizieren kann, also DAOs. Und damit ist dann auch eigentlich klar, was wohin gehört. Ein DTO besitzt nur Attribute, die den Zustand seines zugehörigen Datensatzes in der Datenbank repräsentieren. Die Verarbeitung davon übernimmt das dazugehörige DAO.
Wenn man jetzt sagt, dass man ein bisschen stärker in Richtung Domain-Objects gehen will und den DTOs somit ein bisschen mehr Logik zutraut, dann kann man das ja machen, aber dann würde ich das nur auf das Nötigste beschränken, sprich Methoden wie save, delete, update und Getter für Objekte, die eine relationale Beziehung haben, z.B. getAuftraege. Filterungen wie getAuftraegeAbDatum und dergleichen aber nicht, das ist dann wieder Aufgabe des DAOs und es würde das DTO auch ziemlich unübersichtlich und chaotisch aussehen lassen. Jedenfalls sind diese Methoden nicht in der DTO-Klasse selbst ausimplementiert, sondern sind im Grunde nur Delegationen an die richtigen DAOs und dienen nur zur Vereinfachung, damit man sich für solche Aktionen, die ja alle paar Zeilen Code auftauchen können, nicht an das DAO wenden muss und der Code liest sich dadurch sicherlich auch ein Stück weit eleganter. Aber dennoch ist die Implementierung beider Parteien klar getrennt, selbst wenn man ein Domain-Driven-Model fahren will.
Natürlich hängt das alles auch wieder vom Fall ab, weil das, was ich hier beschrieben habe, könnte schon viele verwirren und aus dem Spiel nehmen, weil das nötige Wissen dazu fehlt und es ist schon eine ziemlich strikte Vorgehensweise, die für eine kleine Hobbyanwendung sicherlich zu viel des Guten ist, da hier die Anwendungsschichten klar getrennt werden, somit auch mit entsprechendem Aufwand verbunden und welcher Hobbyprogrammierer wird das schon machen. Im Businessbereich muss man sowas ja auch nur noch bedingt selbst implementieren dank SpringData und Co. Aber dennoch ist wohl entscheidend was der Kern der Aufmerksamkeit sein soll. Ich selbst würde das jedenfalls nicht in einer All-in-One-Klasse zusammenpacken, sondern klar getrennte Wege gehen und bestenfalls eine passende Fassade bereit stellen. Denn selbst wenn man sich sagt, Kunden und Aufträge haben eine Beziehung zu einander, dennoch sind das ja zwei verschiedene Zugriffsbereiche. Was ist, wenn ich nur eine Auftrags-Id habe und den Kunden gar nicht kenne? Wie soll ich dann den Auftrag laden, wenn ich dafür erst den Kunden brauche? Man könnte dafür ja auch wieder eine Methode im Manager implementieren, der den Auftrag anhand der ID laden kann, aber wie schon gesagt, das lässt die Grenzen verschwimmen und wenn dann noch Lieferanten, Hersteller, etc. hinzu kommen, dann wird das ganze nur noch chaotischer.
