LINQ to SQL Entitäts- und Datenkontextklassen: Kapselung von Geschäftsobjekten

Question

Was sind Ihre bevorzugten Methoden, um LINQ to SQL-Entitätsklassen und Datenkontextklassen in Geschäftsobjekte zu kapseln?

Was haben Sie in einer bestimmten Situation für gut befunden?

Haben Sie bestimmte Muster erfunden oder übernommen?

Answer 1

Ich habe einige Experimente mit Entity Framework und Linq to Entities als eine Möglichkeit, meinen Client-Code weiter von der Datenbank zu trennen, aber ich fand es schwerfällig zu bedienen und war besorgt über die Leistung.

In meinem aktuellen Projekt verwende ich Linq to SQL als meine Datenschicht, habe aber separate Klassen, in denen ich alle Linq-Abfragen implementiere. Die Klassen geben Entitäten zurück, die in meinem Linq to SQL-Kontext definiert sind, aber die Abfragen sind in Methoden versteckt.

Answer 2

Ich fand die Artikel von Ian Cooper auf CodeBetter.de y Stephen Walther Serie von unschätzbarem Wert für das Verständnis der Notwendigkeit, zuerst die POCO-Entitäten zu schreiben und sie dann auf die Datenbank abzubilden, anstatt es andersherum zu machen (was ich immer getan habe).

Answer 3

Ich spiele mit der Idee, eine separate Schicht von OO-Modell (bessere Unterstützung für OO-Praktiken) zu haben, aber das LINQ to SQL unter der Haube verwenden. Die Idee ist, eine XML-Datei zu haben, die ein benutzerdefiniertes Tool verwendet, um den Code zu generieren. Da LINQ to SQL-Entitäten für meine Vorlieben zu unübersichtlich sind, werde ich automatisch neue Klassen generieren, die ich als Entitäten verwende, und natürlich wird der DataContext für den Client-Code vollständig verborgen sein. Die kurze Antwort lautet also: Erstellen Sie neue Entitätsklassen, aber verwenden Sie die zugrunde liegenden LINQ to SQL-Entitäten und den DataContext.