LINQ und LINQ to SQL
Neulich erhielt ich eine E-Mail mit einigen Fragen zur Verwendung von “LINQ to SQL” in n-Tier-Applikationen, die ich hier anonymisiert beantworten möchte:
Wie sieht Microsoft beim Einsatz von “LINQ to SQL” die Machbarkeit von n-Tier-Applikationen, die über eine separate Datenzugriffsschicht verfügen?
Da ich nicht Microsoft bin und auch kein offizielles Statement von Microsoft zu dieser Problematik kenne, kann ich diese Frage so nicht beantworten. Ich kann nur sagen, dass es Beispiel-Applikationen von Microsoft gibt, in denen durchaus “LINQ to SQL” innerhalb der Datenzugriffsschicht eingesetzt wird.
Wenn ich das richtig sehe, krankt “LINQ to SQL” bei seiner Nutzung mit .NET daran, dass ich bei der Nutzung aller automatisch generierten Objekte auf allen Ebenen der Anwendung einen Verweis auf “LINQ to SQL” benötige, oder?
Wenn man die automatisch generierten Objekte in der ganzen Applikation nutzen möchte, ist das sicher so. Aufgrund von der Austauschbarkeit der Datenzugriffsschicht würde ich allerdings empfehlen diese automatisch generierten Objekte nicht über alle Schichten hinweg zu verwenden, sondern “LINQ to SQL” komplett in der Datenzugriffsschicht zu kapseln.
Oder ich führe eine (aufwändig zu implementierende) Mapping-Schicht ein, in der ich die “LINQ to SQL”-generierten Datenklassen in anwendungsinterne Objekte übersetze.
Das wäre eine Möglichkeit, aber aus meiner Sicht nicht empfehlenswert. Ich würde bei einer klassischen 3-Schicht-Architektur eine vierte parallele vertikale Schicht einbinden, welche die Datenobjekte enthält die über alle Schichten hinweg zur Verfügung stehen sollen.
Die Datenzugriffsschicht ist dann verantwortlich für das bereitstellen der Daten und das Mappen der Daten in die Datenobjekte der vierten parallelen vertikalen Schicht.
Für den Fall, dass mal per “LINQ to XML” auf eine XML-Datenbasis zugegriffen werden soll, muss so nur die Datenzugriffsschicht ausgetauscht werden.
Auch wenn ich Benutzeroberfläche (Grids, etc.) an “LINQ to SQL”-Results binden möchte, habe ich das Problem, dass ich damit ja die Datenlogik in die GUI ziehe, und damit die eigentlich unterste mit der eigentlich obersten Schicht verbinde...?
Auch das ist ein Grund für die oben beschriebene parallele vertikale Anwendungsschicht. “LINQ to SQL” ist auf diese Art komplett von den anderen Schichten entkoppelt und die Datenzugriffsschicht liefert nur die gewünschten Objekte.
