Verwirrung um ORM: LINQ-to-SQL oder ADO.NET Entity Framework?
Seite 3: Tools und Navigation
Werkzeuge
Auch bei der Werkzeugunterstützung zeigen sich Unterschiede: Visual Studio 2008 bietet für LINQ-to-SQL einen Designer, den man per Drag&Drop aus dem Server Explorer oder Datenbankexplorer füttern kann. Dabei entsteht eine .dbml-Datei in XML-Form. EF verwendet für die Interaktion mit der Datenbank einen Assistenten – umständlicher. Er erstellt die Abbildungsdatei (*.edmx, ebenfalls in XML-Form). Danach kann man die Entitäten mit einem Designer visuell positionieren und die Abbildungen anpassen. Doch hier kommt es zu größeren Hakeleien, zum Beispiel beim Löschen von Entitäten. Wieder ist es die Firma Devart, die mit dem mächtigeren Designer Entity Developer die von Microsoft gelassene Lücke füllt.
Persistence Ignorance
Der jeweilige Assistent beziehungsweise Designer erzeugt eine XML-Datei und Programmcode: eine Klasse pro Entität im Modell sowie eine Kontext-Klasse, die den Einstiegspunkt für alle Zugriffe bildet.
Im Entity Framework sind die Entitätsklassen von System.Data.Objects.DataClasses.EntityObject abgeleitet, und die Kontextklasse stammt von System.Data.Objects.ObjectContext ab. 1:n-Assoziationen sind Instanzen der generischen Klasse System.Data.Objects.DataClasses.EntityCollection. Ein Paar von zwei Attributen stellt 1:1-Assoziationen dar: Einerseits gibt es ein einfaches Attribut vom Typ der assoziierten Klasse und andererseits ein Referenzattribut vom generischen Typ System.Data.Objects.DataClasses.EntityReference.
Hier ist LINQ-to-SQL flexibler, weil – zumindest für die Entitätsklassen – keine Basisklasse zum Einsatz kommt. Assoziationen zu anderen Entitätsklassen aber sind entweder vom Typ EntityRef (Einzelobjekt, also für 1:0/1-Beziehungen) oder EntitySet (Mengenobjekte für 1:0/n-Beziehungen). Hier gibt es also auch Restriktionen.
EF 2.0 soll bei der Gestaltung der Objektmodelle völlig flexibel sein, weil dort die Abhängigkeit von Basisklassen und bestimmten Mengenklassen entfallen, sodass man von "POCOs" (Plain Old CLR Objects) oder "Persistence Ignorance" sprechen kann.
Navigation und Fremdschlüssel
Sowohl LINQ-to-SQL als auch das Entity Framework übernehmen Beziehungen aus dem Datenbankmodell und erzeugen Attribute für die Navigation zwischen den Entitätsklassen. So kann man von einem Rechnungsobjekt über das Attribut "Positionen" die Liste der zugehörigen Rechnungspositionen erhalten oder auf einer Rechnungsposition über "Rechnung" zum übergeordneten Datensatz zurück navigieren. Diese Navigationsattribute lassen sich zum Zuordnen von Entitäten nutzen; das ORM-Werkzeug erzeugt in diesem Fall passende Tabelleneinträge.
Ein entscheidender Unterschied liegt darin, dass LINQ-to-SQL sowohl die Navigationsattribute als auch die direkte Arbeit mit Fremdschlüsseln unterstützt. Letzteres ist sinnvoll, wenn man eine Rechnungsposition einer Rechnung zuordnen will, von der man nur die Nummer kennt. In EF 1.0 gibt es dieses Fremdschlüsselattribut nicht, man muss also immer über die Objekte zuordnen – was zusätzlich Rechenzeit kostet. Im genannten Beispiel wäre erst das Rechnungsobjekt anhand der Rechnungsnummer zu laden, bevor man es zuordnen kann, obwohl die Anwendung das Objekt gar nicht benötigt.
