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
</ul>

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.

[ Download Sourcecode ]