Guten Morgen zusammen,
ich mache mir mal wieder Gedanken über die Dreischicht-Architektur. Ich möchte meine Anwendung in den Schichten (von unten nach oben) Datenhaltung, Applikation und Präsentation aufteilen.
Datenhaltung:
Hier habe ich ein Entitätsobjekt, welches einen beispielsweise einen Datensatz in der Datenbank entspricht. Das zugehörigen DAO-Objekt kann das Entitätsobjekt in die Datenbank schreiben, lesen und ändern. Referenzielle Integrität werden in dieser Schicht nicht realisiert. Bedeutet, das eine Referenz lediglich durch die entsprechende ID dargestellt wird.
Applikation.
Die Applikationsschicht beinhaltet Business-Objekte (BO). Diese Business-Objekte sind zu einem hohen Grad identisch mit den Entitägsobjekten. Hier habe ich jedoch die Referenzen aufgelöst. Bedeutet ein BO hat die Referenz auf ein weiteres BO. Die BO werden durch Adapter erstellt. In diesem Adapter ist die Logik enthalten wie ich aus Entitätsobjekten die BO erstellen kann. Beispiel:
Die Präsentationsschicht ist für meine jetzigen Überlegungen nicht von Belang.
Ich mache mir in regelmäßigen Abständen Gedanken über die Sinnhaftigkeit. Dabei überlege ich ob ich die Objekte in meiner Anwendung generell als BO darstelle. Dementsprechend die Schichten Datenhaltung und Applikation nicht trenne. Mit ist durchaus bewusst, dass es von der Anwendung abhängig ist ob die Dreischicht-Architektur sinnvoll ist oder nicht.
Meine Frage wäre, wie Ihr eine Aufteilung der Schichten durchführt. Solltet Ihr nicht nach der Dreischicht Architektur vorgehen würde mich euer Ansatz auch interessieren.
Gruß
dbausnnd
ich mache mir mal wieder Gedanken über die Dreischicht-Architektur. Ich möchte meine Anwendung in den Schichten (von unten nach oben) Datenhaltung, Applikation und Präsentation aufteilen.
Datenhaltung:
Hier habe ich ein Entitätsobjekt, welches einen beispielsweise einen Datensatz in der Datenbank entspricht. Das zugehörigen DAO-Objekt kann das Entitätsobjekt in die Datenbank schreiben, lesen und ändern. Referenzielle Integrität werden in dieser Schicht nicht realisiert. Bedeutet, das eine Referenz lediglich durch die entsprechende ID dargestellt wird.
Applikation.
Die Applikationsschicht beinhaltet Business-Objekte (BO). Diese Business-Objekte sind zu einem hohen Grad identisch mit den Entitägsobjekten. Hier habe ich jedoch die Referenzen aufgelöst. Bedeutet ein BO hat die Referenz auf ein weiteres BO. Die BO werden durch Adapter erstellt. In diesem Adapter ist die Logik enthalten wie ich aus Entitätsobjekten die BO erstellen kann. Beispiel:
Der KundenAuftragAdapter kennt den KundenAuftragDao. Daraus holt er sich eine List von KundenAuftragEntity. Aus dieser Liste wird eine Liste KundenAuftragBo erstellt, in der eine Referenz auf das KundenBo Objekt enthalten ist.
Präsentation
Die Präsentationsschicht ist für meine jetzigen Überlegungen nicht von Belang.
Ich mache mir in regelmäßigen Abständen Gedanken über die Sinnhaftigkeit. Dabei überlege ich ob ich die Objekte in meiner Anwendung generell als BO darstelle. Dementsprechend die Schichten Datenhaltung und Applikation nicht trenne. Mit ist durchaus bewusst, dass es von der Anwendung abhängig ist ob die Dreischicht-Architektur sinnvoll ist oder nicht.
Meine Frage wäre, wie Ihr eine Aufteilung der Schichten durchführt. Solltet Ihr nicht nach der Dreischicht Architektur vorgehen würde mich euer Ansatz auch interessieren.
Gruß
dbausnnd