N-tier en externe toepassingen met LINQ naar SQL
U kunt n-tier- of multilaagtoepassingen maken die LINQ gebruiken voor SQL. Normaal gesproken bevinden de LINQ naar SQL-gegevenscontext, entiteitsklassen en queryconstructielogica zich op de middelste laag als de DATA Access Layer (DAL). Bedrijfslogica en niet-permanente gegevens kunnen volledig worden geïmplementeerd in gedeeltelijke klassen en methoden van entiteiten en de gegevenscontext, of kunnen worden geïmplementeerd in afzonderlijke klassen.
De client- of presentatielaag roept methoden aan op de externe interface van de middelste laag en de DAL op die laag voert query's of opgeslagen procedures uit die zijn toegewezen aan DataContext methoden. De middelste laag retourneert de gegevens doorgaans als XML-weergaven van entiteiten of proxyobjecten.
Op de middelste laag worden entiteiten gemaakt door de gegevenscontext, die hun status bijhoudt en het uitstellen van het laden van bestanden beheert en wijzigingen in de database indient. Deze entiteiten zijn 'gekoppeld' aan de DataContext. Nadat de entiteiten echter via serialisatie naar een andere laag zijn verzonden, worden ze losgekoppeld, wat betekent dat de DataContext status niet meer wordt bijgehouden. Entiteiten die door de client worden teruggestuurd voor updates, moeten opnieuw worden gekoppeld aan de gegevenscontext voordat LINQ naar SQL de wijzigingen naar de database kan verzenden. De client is verantwoordelijk voor het leveren van oorspronkelijke waarden en/of tijdstempels aan de middelste laag als deze zijn vereist voor optimistische gelijktijdigheidscontroles.
In ASP.NET toepassingen beheert het LinqDataSource grootste deel van deze complexiteit. Zie Overzicht van linqDataSource-webserverbeheer voor meer informatie.
Aanvullende resources
Zie de volgende onderwerpen voor meer informatie over het implementeren van n-tier-toepassingen die LINQ gebruiken voor SQL:
Zie Werken met gegevenssets in n-laag-toepassingen voor meer informatie over toepassingen met n-laag die gebruikmaken van ADO.NET DataSets.