Eager Loading

Eintrag zuletzt aktualisiert am: 05.04.2011

Die Definition der Abfrage selbst ist aber noch nicht alles, was über die tatsächlich zu ladenden Objekte entscheidet. Eine entscheidende Frage für die Leistungsfähigkeit von ORM ist die Frage, wann verbundene Objekte zu laden sind. Wenn man zu einem Flug sofort alle Buchungen und die dazugehörigen Passagier- und Personendaten lädt, lädt man unter Umständen mehr als wirklich gebraucht wird. Holt man die Daten jedoch nicht, müssen sie beim Zugriff auf eine Objektreferenz nachgeladen werden. Das Nachladen bei Bedarf nennt man Lazy Loading, Deferred Loading oder Delayed Loading im Gegensatz zum Eager Loading (alias Immediate Loading). Lazy Loading ist der Standard in allen ORM-Werkzeugen, Eager Loading kann man auf Ebene einer Datenbankverbindung (alias Datenkontext oder Data Scope) oder einer einzelnen Anfrage steuern.

Lazy Loading beinhaltet eine besondere Herausforderung, denn das ORM-Werkzeug muss jeglichen Zugriff auf alle Objektreferenzen »abfangen«, um hier bei Bedarf die verbundenen Objekte nachladen zu können. Dieses Abfangen erfolgt durch die Verwendung bestimmter Klassen für Einzelreferenzen und Mengenklassen. Der Unterschied zwischen den ORM-Werkzeugen liegt hier darin, ob der Entwickler diese Klassen explizit im Code verwenden muss oder ob das ORM-Werkzeug diese beim Kompilieren oder zur Laufzeit austauscht.

Die Wahl zwischen Lazy Loading und Eager Loading ist oft auch die Wahl zwischen Pest und Cholera: Wenn man nicht genau weiß, ob die zusätzlichen Daten benötigt werden oder nicht, dann kann es ungünstig sein, sie direkt zu laden. Es kann aber auch ungünstig sein, sie später nachladen zu müssen. Wichtige Entscheidungskriterien sind:
 Wie wahrscheinlich ist, dass die Daten benötigt werden?
 Wie groß ist die Datenmenge?
 Kann ich überhaupt später die Daten einfach nachladen? (Wenn die Daten zwischenzeitlich serialisiert wurden, ist ein automatisches Nachladen in der Regel nicht mehr möglich!)