Die Architektur des EOF setzt sich aus drei Schichten zusammen:
* Interface Layer: Stellt Methoden für die Datendarstellung zur Verfügung.
* Control Layer: Verwaltet den Graphen der Enterprise Objekte.
* Access Layer: Erzeugt Enterprise Objekte aus Datenbankzeilen.
Abb. 35: Datenfluß in einer EOF-Anwendung.
Quelle: Entnommen aus [NTY398]
* Im Access Layer werden die Daten in Form von Datenbankzeilen aus der Datenbank übernommen.
* Im Adaptor Lavel werden diese Daten als Wert/Name-Paar in NSDictionarie-Objekte verpackt. Als Schlüssel dient der Name der Datenbankspalte und als Wert wird die Belegung dieser Spalte in der aktuellen Zeile eingesetzt.
* Im Database Lavel werden aus den NSDicionary-Objekten EOF-Objekte erzeugt. Das bedeutet, daß Methoden die für die Erstellung der Anwendungslogik hinzugefügt werden.
* Über den DataSource werden die Enterprise Objects in den Interface Layer gereicht. Die sogenannte DisplayGroup, die von einer Instanz der EODisplayGoup vertreten wird, verwaltet die Objekte für die Darstellung.
* Wenn sich Enterprise Objekte geändert haben, sorgt ein Benachrichtigungsmechanismus dafür, daß die EODisplayGroup-Instanz von der EOAssociation-Instanz informiert wird, die Änderungen nachzuziehen. Die Änderungen werden von den entsprechenden Instanzen entgegengenommen und aktualisieren das User-Interface.
Da für die Formulierung des Objektmodels ein sehr gutes grafisches Tool, der EOModeler, zur Verfügung steht, kommt der Anwendungsentwickler mit dem Objektmodel selten weiter als bis zur EOF-Schnittstelle und ist nicht gezwungen, auf grundlegende Mechanismen zurückzugreifen.
