Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
LINQ to SQL wurde speziell für die Verwendung auf der mittleren Ebene in einer lose gekoppelten Datenzugriffsebene (DAL) wie einem Webdienst entwickelt. Wenn es sich bei der Präsentationsebene um eine ASP.NET Webseite handelt, verwenden Sie das LinqDataSource Webserversteuerelement, um die Datenübertragung zwischen der Benutzeroberfläche und LINQ to SQL auf der mittleren Ebene zu verwalten. Wenn die Präsentationsebene keine ASP.NET Seite ist, müssen sowohl die mittlere ebene als auch die Präsentationsleiste einige zusätzliche Aufgaben ausführen, um die Serialisierung und Deserialisierung von Daten zu verwalten.
Einrichten von LINQ to SQL auf der mittleren Ebene
In einem Webdienst oder einer n-Ebene-Anwendung enthält die mittlere Ebene den Datenkontext und die Entitätsklassen. Sie können diese Klassen manuell erstellen oder entweder SQLMetal.exe oder den objektrelationalen Designer verwenden, wie in der Dokumentation beschrieben. Zur Entwurfszeit haben Sie die Möglichkeit, die Entitätsklassen serialisierbar zu machen. Weitere Informationen finden Sie unter How to: Make Entities Serializable. Eine weitere Option besteht darin, einen separaten Satz von Klassen zu erstellen, die die zu serialisierenden Daten kapseln und dann in diese serialisierbaren Typen projizieren, wenn Sie Daten in Ihren LINQ-Abfragen zurückgeben.
Anschließend definieren Sie die Schnittstelle mit den Methoden, die von den Clients aufgerufen werden, um Daten abzurufen, einzufügen und zu aktualisieren. Die Schnittstellenmethoden umschließen Ihre LINQ-Abfragen. Sie können jede Art von Serialisierungsmechanismus verwenden, um die Remotemethodenaufrufe und die Serialisierung von Daten zu verarbeiten. Die einzige Anforderung ist, dass Sie einen Serialisierer verwenden, der zyklische oder bidirektionale Beziehungen in Ihrem Objektmodell unterstützt, wie beispielsweise zwischen Kunden und Bestellungen im Standard-Northwind-Objektmodell. Die Windows Communication Foundation (WCF) DataContractSerializer unterstützt bidirektionale Beziehungen, aber der XmlSerializer, der mit Nicht-WCF-Webdiensten verwendet wird, nicht. Wenn Sie sich für die Verwendung des XmlSerializers entscheiden, müssen Sie sicherstellen, dass ihr Objektmodell keine zyklischen Beziehungen aufweist.
Weitere Informationen zu Windows Communication Foundation finden Sie unter Windows Communication Foundation Services 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 N-Tier Business Logic.
Definieren der serialisierbaren Typen
Die Client- oder Präsentationsebene muss Typdefinitionen für die Klassen aufweisen, die sie von der mittleren Ebene erhalten. 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. In jedem Fall ist LINQ to SQL völlig unkoncerniert darüber, wie die Präsentationsebene diese Typdefinitionen abruft. Beispielsweise könnte die Präsentationsebene WCF verwenden, um die Typen automatisch zu generieren, oder sie könnte eine Kopie einer DLL haben, in der diese Typen definiert sind, oder sie könnte einfach seine eigenen Versionen der Typen definieren.
Abrufen und Einfügen von Daten
Die mittlere Ebene definiert eine Schnittstelle, die angibt, wie die Präsentationsebene auf die Daten zugreift. Beispiel 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. Die Präsentationsleiste sendet oder empfängt Abfragevariablen nie direkt an oder von der mittleren Ebene. Die beiden Ebenen tauschen Werte, Objekte und Sammlungen konkreter Daten aus. Nachdem eine Auflistung empfangen wurde, kann die Präsentationsebene LINQ to Objects verwenden, um sie bei Bedarf abzufragen.
Beim Einfügen von Daten kann die Präsentationsebene ein neues Objekt erstellen und an die mittlere Ebene senden, oder es kann die mittlere Ebene das Objekt basierend auf den von ihr bereitgestellten Werten konstruieren lassen. Im Allgemeinen unterscheidet sich das Abrufen und Einfügen von Daten in n-Ebenen-Anwendungen nicht wesentlich vom Prozess in 2-Ebenen-Anwendungen. Weitere Informationen finden Sie unter Abfragen der Datenbank und Vornehmen und Übermitteln von Datenänderungen.
Nachverfolgen von Änderungen für Update- und Löschvorgänge
LINQ to SQL unterstützt die optimistische Parallelität basierend auf Zeitstempeln (auch als RowVersions bezeichnet) und auf originalen Werten. Wenn die Datenbanktabellen Zeitstempel haben, benötigen Aktualisierungen und Löschungen wenig zusätzliche Arbeit auf der mittleren oder präsentationsebene. Wenn Sie jedoch Originalwerte für optimistische Parallelitätsprüfungen verwenden müssen, ist die Präsentationsebene dafür verantwortlich, diese Werte zu verfolgen und sie zurückzusenden, wenn Aktualisierungen durchgeführt werden. Dies liegt daran, dass Änderungen, die an Entitäten auf der Präsentationsebene vorgenommen wurden, nicht auf der mittleren Ebene nachverfolgt werden. Tatsächlich werden sowohl der ursprüngliche Abruf einer Entität als auch die letztlich daran vorgenommene Aktualisierung in der Regel von zwei vollständig getrennten Instanzen der DataContext durchgeführt.
Je größer die Anzahl der Änderungen, die die Präsentationsebene vornimmt, desto komplexer wird es, diese Änderungen nachzuverfolgen und sie wieder auf die mittlere Ebene zu packen. Die Implementierung eines Mechanismus für die Kommunikation von Änderungen liegt vollständig bei der Anwendung. Die einzige Anforderung besteht darin, dass LINQ to SQL die ursprünglichen Werte erhalten muss, die für optimistische Parallelitätsprüfungen erforderlich sind.
Weitere Informationen finden Sie unter Data Retrieval and CUD Operations in N-Tier Applications (LINQ to SQL).