HowTo: O/R Mapper LINQ to SQL – Einführung in den Designer & 1:N Beziehungen
Im letzten HowTo rund um LINQ to SQL ging es mehr darum, ein Grundverständnis zu vermitteln. Das manuelle Mapping ist eine Methode, wie man LINQ to SQL nutzen kann – mit Visual Studio 2008 (selbst in der Express Edition) ist auch ein LINQ to SQL Designer Template mit dazugekommen:
Variante A: Unser einfaches Costumer Beispiel diesmal mit dem Designer
Schritt 1: .dbml Datei erstellen
Nachdem eine solche “xxx.dbml” Datei erstellt hat – in unserem Beispiel wollen wir wieder die Costumer Tabelle aus der Northwind Database auslesen (Installationsanleitung), daher “Costumers.dbml” – sieht man nur eine solche Meldung:
Schritt 2: DB Verbindung hinzufügen
Über den DB Explorer legen wir eine Verbindung zu einem Microsoft SQL Server Database File her:
Danach wählen wir unserer Northwind.MDF (Standardinstallationspfad: “C:\SQL Server 2000 Sample Databases\NORTHWND.MDF”).
Schritt 3: Tabellen auf die Designer Oberfläche ziehen
Im nächsten Schritt ziehen wir einfach die jeweiligen Tabellen die wir haben wollen (in unserem Fall die Costumers) auf die Oberfläche:
Visual Studio 2008 erstellt daraufhin folgende Sturktur:
- Customer.dbml.layout = XML Beischreibung
- Costomer.dbml.cs = Der eigenliche Code mit sämtlichen Attributen und dem
Allerdings landet in der Customer.designer.cs nicht nur wie bei dem vorherigen HowTo die MappingInformationen der Tabelle, sondern es wird zugleich auch gleich eine spezielle DataContext Klasse “CostumerDataContext” gebildet:
Die Interfaces INotifyPropertyChanging & INotifyPropertyChanged wurden ebenfalls implementiert – WPF benutzt dies zum Beispiel im Kontext mit Databinding, was hier ja quasi ebenfalls passiert.
Schritt 4: Daten abrufen, verändern und löschen
Jetzt können wir die selben Befehle ausführen, wie in unserem anderen Beispiel:
using System; using System.Collections.Generic; using System.Linq; using System.Data.Linq; using System.Text; namespace LinqToSqlDesigner { class Program { static void Main(string[] args) { CustomerDataContext context = new CustomerDataContext(); Table<Customer> customerTable = context.GetTable<Customer>(); var customerResult = from customer in customerTable where customer.City == "London" select customer; foreach (Customer oneCustomer in customerResult) { Console.WriteLine(oneCustomer.CompanyName); } Console.ReadLine(); } } }
Diese Variante ist so nicht zu empfehlen – jedenfalls sollte die dbml nicht nach einer Tabelle genannt werden. In der nächsten Variante sieht man gut, wie man eine größere Datenbank mit einer dbml abbilden kann.
Variante B: 1:N Beziehungen mit dem Designer
Das war ja jetzt nicht sonderlich spannend, allerdings ist es auch möglich direkt im Designer 1:N Beziehungen vorzunehmen.
Dazu erstellen wir uns wieder unsere LINQ to SQL “Northwind.dbml” und wählen jetzt mal den Customers und die Orders aus:
Der “Pfeil”, also die Association, zwischen CustomerID aus der Customer Klasse/Tabelle und der CustomerID aus der Order Klasse/Tabelle wird automatisch gebildet (wahrscheinlich weil diese Assoziation bereits im DB System bekannt ist – ob das Mapping auch anhand des Namens erfolgt, habe ich momentan nicht getestet). Man kann diese Assoziation allerdings auch selber bearbeiten, indem man in den Eigenschaften des “Pfeils” schaut:
Eigenschaften:
Der LINQ to SQL O/R Designer besitzt ebenso eine eigene Toolbox, mit welchen man auch einige eigene Sachen erstellen kann:
Wenn man nun noch zwei weitere Tabellen in den Designer zieht, macht das langsam einen recht schicken Eindruck:
Dadurch habe wir innerhalb weniger Minuten bereits folgende fertige Klassen zur Verfügung:
Jetzt machen wir mal wieder unsere Abfrage um zu zeigen, was man damit machen kann:
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data.Linq; namespace LinqToSqlDesigner { class Program { static void Main(string[] args) { NorthwindDataContext context = new NorthwindDataContext(); Table<Customer> customerTable = context.GetTable<Customer>(); var cust = from c in customerTable where c.City == "London" select c; foreach(Customer customer in cust) { Console.WriteLine(customer.CompanyName); if(customer.Orders.Count > 0) { Console.WriteLine("Customer Orders"); foreach(Order order in customer.Orders) { if(order.Order_Details.Count > 0) { Console.WriteLine(" - " + order.Order_Details[0].Product.ProductName); } } } } Console.ReadLine(); } } }
Hierbei holen wir uns erst alle Kunden aus “London”, welche wir auf der Konsole ausgeben. Danach prüfen wir, ob der Kunde eine Bestellung offen hat und welche dazugehörige Produkte er dazu gekauft hat. Resultat:
Was verbirgt sich hinter den 1:N Beziehungen?
Wenn wir jetzt mal in den generierten Code reinschauen, z.B. bei der Customer Klasse, finden wir folgenden Abschnitt:
private EntitySet<Order> _Orders; public Customer() { this._Orders = new EntitySet<Order>(new Action<Order>(this.attach_Orders), new Action<Order>(this.detach_Orders)); OnCreated(); }
Ein “EntitySet” (Streng Typisiert) dient dabei als Datenspeicher der Beziehungsdaten. Das Gegenstück von EntitySet ist EntityRef.
Schematisch wäre dies grob so:
Der Customer hat Orders in seinem EnitySet gespeichert. Die Orders halten wiederrum die Verweise als EntityRef fest. Nachzulesen lässt sich das (und auch das Thema Many-to-Many-Relations, auch in der MSDN: How to: Map Database Relationships (LINQ to SQL)
Natürlich kann man auch mit dieser Basis die ganzen CRUD Sachen aus diesem Blogpost machen.
Fazit
LINQ to SQL bietet einen sehr netten Designer, mit dem man schnell zu Ergebnissen kommt. Wie ich selber aber gemerkt habe, ist sicherlich erst eine Grundsätzlich Einarbeitung in den Abfrage Syntax von LINQ notwenidig um gute und performante Abfragen zu gestalten.
Jeder der mit Microsoft SQL und .NET 3.5 zutun hat, sollte sich die Möglichkeiten von LINQ to SQL nicht entgehen lassen!
Es gibt sicherlich noch mehr Themen rund um LINQ to SQL – das war ja auch erst der zweite Post zu diesem Thema 
Downloaden könnt ihr das Testprojekt auch, allerdings musste ich aus Platzgründen die Northwind.mdf (und die log Datei) aus dem Verzeichnis entfernen – installiert die Northwind Datenbank einfach und kopiert die beiden Datein mit in das Verzeichnis. Visual Studio 2008 (mit Administrator Rechten) ist bei .NET 3.5 Pflicht.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Jan Waiz
27. February 2008
Guter Artikel und sehr gut geeignet für allererste Einstiegsdröhnungen zwecks Frustvermeidung
Mein Dank dafür und
mfg
Jan Waiz
Andreas
12. April 2008
Hallo und Danke für den Artikel,
leider habe ich Probleme eine Verbindung mit Visual Studio (Datenquelle auswählen) zu einem Microsoft SQL herzustellen, der sich bei mir im Netzwerk befindet.
Wie funktioniert das?
Heiko
6. June 2009
Hallo,
ist es eigentlich möglich 2 unterschiedliche Linq-to-Sql Klassen zu durchsuchen und das Ergebniss in einer Liste auszugeben? Habe bisher leider keine möglichkeiten gefunden… vielleicht kannst du mir ja einen tip geben?!
Ansonsten sehr schöner Artikel!
Heiko