Best Practise Facade und DAOs

[y0dA]

Wir benutzen in unsere Applikation Facades für jede Domainklasse welche wiederum eine Tabelle in der DB repräsentiert. Nun haben wir aber auch andere Bereiche wo DB Abfragen gemacht werden müssen - bspw. bei Statistiken.

Wie geht man hierbei nun vor? Wir haben nur Facades für die Domainklassen, kann mann dann auch, eben bspw. für die Statistiken, separat DAOs anlegen oder zerstört das das Konzept? Wie geht ihr hierbei vor?

 

[tfa]

Ich würde für die Statistik-Objekte eine eigene Klasse anlegen und eine entsprechende DB-Zugriffsklasse (muss ja nicht DAO heißen). Statistik-Objekte unterscheiden sich (pragmatisch) zwar von den normalen Fachklassen, aber was wäre das alternative Konzept?

 

[y0dA]

Ich würde für die Statistik-Objekte eine eigene Klasse anlegen und eine entsprechende DB-Zugriffsklasse (muss ja nicht DAO heißen). Statistik-Objekte unterscheiden sich (pragmatisch) zwar von den normalen Fachklassen, aber was wäre das alternative Konzept?

Aber auch nicht Facade heissen oder wie? Unsere Facades implementieren ja CRUD und hierbei das wäre für die Statistik Thematik nicht so prickelnd weil man mit selbigen ja kein CREATE, UPDATE etc durchführen sollte.
Mir geht es nur darum dass ich, sofern ich die Statistik Thematik anders implementieren (eben als DAO bspw.), die DB Zugriffsschicht insofern verändere dass dann quasi 2 "Patterns" dafür existieren - eben Facades und DAOs. Oder sollte ich auch Facades machen für die Statistiken und das CRUD weglassen?

 

[tfa]

Keine Ahnung, was ihr hier mit Fassaden macht. Wenn ich read-only Daten habe, gibt es eben nur R und kein C, U, D.
Ich meine, Hauptsache der Zugriff wird vernünftig gekapselt und vom Rest getrennt. Also kein verstreutes Statistik-SQL in irgendwelchen Controller- oder GUI-Klassen. Wie man das jetzt nennt ist doch nur eine Geschmacksfrage.