LINQ to SQL-N-Tier mit Webdiensten
LINQ to SQL wurde speziell zur Verwendung auf der mittleren Ebene in einer lose verknüpften Datenzugriffsebene (Data Access Layer, DAL), z. B. einem Webdienst, entwickelt. Wenn es sich bei der Präsentationsebene um eine ASP.NET-Webseite handelt, können Sie die Datenübertragung zwischen der Benutzeroberfläche und LINQ to SQL auf der mittleren Ebene mithilfe des LinqDataSource-Webserversteuerelements verwalten. Wenn es sich bei der Präsentationsebene nicht um eine ASP.NET-Seite handelt, müssen sowohl die mittlere Ebene als auch die Präsentationsebene zusätzliche Arbeit leisten, um die Serialisierung und Deserialisierung von Daten zu verwalten.
Einrichten von LINQ to SQL auf der mittleren Ebene
In einem Webdienst oder einer N-Tier-Anwendung enthält die mittlere Ebene den Datenkontext und die Entitätsklassen. Sie können diese Klassen manuell erstellen, indem Sie entweder SQLMetal.exe oder O/R-Designer, wie an anderer Stelle in der Dokumentation beschrieben, verwenden. Zur Entwurfszeit können Sie die Entitätsklassen serialisierbar machen. Weitere Informationen finden Sie unter Vorgehensweise: Aktivieren der Serialisierbarkeit von Entitäten (LINQ to SQL). Eine weitere Möglichkeit besteht darin, eine separate Gruppe von Klassen zu erstellen, die die zu serialisierenden Daten kapseln, und dann bei der Rückgabe von Daten in den LINQ-Abfragen in diese serialisierbaren Typen zu projizieren.
Anschließend definieren Sie die Schnittstelle mithilfe der Methoden, die von Clients zum Abrufen, Einfügen und Aktualisieren von Daten aufgerufen werden. Die Schnittstellenmethoden umschließen die LINQ-Abfragen. Sie können einen beliebigen Serialisierungsmechanismus verwenden, um Remotemethodenaufrufe und die Serialisierung von Daten zu behandeln. Wenn Sie in Ihrem Objektmodell über zyklische oder bidirektionale Beziehungen verfügen, z. B. Beziehungen zwischen Customers und Orders im standardmäßigen Northwind-Objektmodell, besteht die einzige Voraussetzung darin, einen Serialisierer zu verwenden, der das Modell unterstützt. Die Windows Communication Foundation (WCF) DataContractSerializer unterstützt im Unterschied zum XmlSerializer, der mit Nicht-WCF-Webdiensten verwendet wird, bidirektionale Beziehungen. Wenn Sie den XmlSerializer verwenden möchten, müssen Sie sicherstellen, dass das Objektmodell keine zyklischen Beziehungen aufweist.
Weitere Informationen zur Windows Communication Foundation finden Sie unter Windows Communication Foundation-Dienste und WCF Data Services in Visual Studio.
Implementieren Sie Geschäftsregeln oder eine andere domänenspezifische Logik, indem Sie die partiellen Klassen und Methoden fürDataContext und die Entitätsklassen verwenden, um LINQ to SQL-Laufzeitereignisse zu verknüpfen. Weitere Informationen finden Sie unter Implementieren von Geschäftslogik (LINQ to SQL).
Definieren serialisierbarer Typen
Die Client- oder Präsentationsebene muss über Typdefinitionen für die Klassen verfügen, die Daten von der mittleren Ebene empfangen. Bei diesen Typen kann es sich um die Entitätsklassen selbst oder um spezielle Klassen handeln, die nur bestimmte Felder aus den Entitätsklassen für das Remoting umschließen. LINQ to SQL braucht sich jedenfalls nicht darum zu kümmern, wie die Präsentationsebene diese Typdefinitionen abruft. Die Präsentationsebene könnte beispielsweise WCF verwenden, um diese Typen automatisch zu generieren, oder sie könnte eine Kopie der DLL nutzen, in der diese Typen definiert sind. Alternativ könnte sie einfach eigene Versionen dieser Typen definieren.
Abrufen und Einfügen von Daten
Die mittlere Ebene definiert eine Schnittstelle, durch die angegeben wird, wie die Präsentationsebene auf die Daten zugreift. Beispielsweise GetProductByID(int productID) oder GetCustomers(). Auf der mittleren Ebene wird vom Methodentext normalerweise eine neue Instanz von DataContext erstellt und eine Abfrage gegen mindestens eine ihrer Tabellen ausgeführt. Die mittlere Ebene gibt dann das Ergebnis als IEnumerable<T> zurück, wobei T entweder eine Entitätsklasse oder ein anderer für die Serialisierung verwendeter Typ ist. Über die Präsentationsebene werden Abfragevariablen nie direkt an die mittlere Ebene gesendet bzw. von ihr empfangen. Die beiden Ebenen tauschen Werte, Objekte und Auflistungen konkreter Daten aus. Nachdem eine Auflistung empfangen wurde, kann die Präsentationsebene LINQ to Objects verwenden, ums sie ggf. abzufragen.
Bein Einfügen von Daten kann die Präsentationsebene ein neues Objekt erstellen und es an die mittlere Ebene senden, oder sie kann das Objekt von der mittleren Ebene auf der Grundlage der von ihr gelieferten Daten erstellen lassen. Im Allgemeinen unterscheidet sich das Abrufen und Einfügen von Daten in N-Tier-Anwendungen nicht von der Vorgehensweise in 2-Tier-Anwendungen. Weitere Informationen finden Sie unter Abfragen der Datenbank (LINQ to SQL) und unter Vornehmen und Übergeben von Datenänderungen (LINQ to SQL).
Nachverfolgen von Änderungen für Update- und Löschvorgänge
LINQ to SQL unterstützt vollständige Parallelität auf der Basis von Timestamps (auch als RowVersions bezeichnet) und ursprünglichen Werten. Wenn die Datenbanktabellen über Timestamps verfügen, ist auf der mittleren oder Präsentationsebene wenig zusätzliche Arbeit für Update- und Löschvorgänge erforderlich. Wenn Sie für Überprüfungen auf vollständige Parallelität jedoch Originalwerte verwenden müssen, ist die Präsentationsebene dafür verantwortlich, diese Werte zu verfolgen und sie bei der Ausführung von Updates zurückzusenden. Dies liegt daran, dass Änderungen, die an Entitäten auf der Präsentationsebene vorgenommen wurden, nicht auf der mittleren Ebene verfolgt werden. Tatsächlich werden das ursprüngliche Abrufen einer Entität und das endgültig vorgenommene Update normalerweise von zwei vollständig getrennten DataContext-Instanzen ausgeführt.
Je größer die Anzahl der Änderungen ist, die von der Präsentationsebene vorgenommen werden, desto komplexer ist das Verfolgen dieser Änderungen und das Zurückpacken auf die mittlere Ebene. Die Implementierung eines Mechanismus zum Kommunizieren von Änderungen liegt vollständig in der Zuständigkeit der Anwendung. Die einzige Voraussetzung besteht darin, dass die ursprünglichen Werte, die für Überprüfungen auf vollständige Parallelität erforderlich sind, LINQ to SQL zur Verfügung gestellt werden müssen.
Weitere Informationen finden Sie unter Datenabruf und CUD-Operationen in N-Tier-Anwendungen (LINQ to SQL).