LINQ vs Datenzugriffsschicht

10

Ich habe mir selbst beigebracht, Datenzugriffscode immer in einer völlig separaten Schicht zu meiner Geschäftslogik und meinem UI-Code zu behandeln. Dies war schon immer eine sehr gute Architektur für mich, und alle „Regeln“ oder Best Practices, die ich sehe, passen immer noch in diesen Codierungsstil, insbesondere in das Prinzip der Einzelverantwortung .

Für die meisten meiner Heimprojekte würde ich mein eigenes ORM verwenden, das ich erstellt habe und das ich immer als Open Source machen wollte. Seitdem ist jedoch LINQ verfügbar geworden, was der Funktionsweise meines ORM sehr ähnlich war (aber ... besser).

Mit meinem eigenen ORM konnte ich bisher nichts tun, was ich jetzt mit LINQ nicht tun kann (außer Teilen der REST-Integration). Meine Frage ist also: Ist LINQ meine neue Datenzugriffsschicht? Benötige ich diese Schicht überhaupt noch? Sollte meine BLL nur direkt mit LINQ sprechen? Oder ist diese schlechte Praxis immer noch?

Bearbeiten:

Die ursprüngliche Frage bezog sich auf LINQ to Entities, aber es gibt viele interessante Antworten zu LINQ to SQL. Was denken die Menschen über beide? Ich nehme an, dass LINQ to SQL einen DAL nicht wirklich ersetzen kann, aber könnte das Entity Framework?

— Connell
quelle

7

Obwohl Sie nur LINQ-Abfragen in Ihre BLL einfügen können, kann dies zu einer Duplizierung des Codes führen. Ich würde immer noch Repositorys erstellen, die ein Wrapper für LINQ-Abfragen sein werden. Dies trennt den Datenbankcode vom BLL-Code und ist nützlich, wenn Sie Ihren Datenzugriffscode ändern möchten (z. B. zu Dapper wechseln oder vorkompilierte Abfragen).

Dies hilft auch beim Testen von Einheiten , da Repositorys leicht verspottet werden können.

— Jakub Konecki
quelle

6

Sie könnten immer noch eine DAL haben, nur könnte sie LINQ to SQL anstelle der zuvor verwendeten verwenden. So mache ich es trotzdem. Lassen Sie Ihre BLL LINQ to SQL nicht direkt verwenden, um auf Daten zuzugreifen.

— neeKo
quelle

Ich bin damit einverstanden, dass LINQ to SQL nur eine Abfragesprache ist, die Sie daran hindern kann, viel Installationscode zu schreiben. Der Datenzugriff in Ihrer Anwendung wird nicht wie bei einem DAL gekapselt.

— Neontapir

Ich bezog mich wirklich auf LINQ to Entities. Ich verwende auch viel LINQ für Objekte, aber ich betrachte dies als Geschäftslogik. Ich verstehe den Unterschied hinter den Kulissen zwischen Entities und LINQ to SQL, aber ich habe LINQ to SQL nie verwendet. Gibt es Unterschiede in der Syntax?

— Connell

2

Bei Linq geht es nicht um Datenzugriff, Sie können Linq für jeden verwenden IEnumerable.

Haben Sie versucht, Ihre Anwendung zu entwerfen, ohne zuerst an die Datenbank zu denken? Implementieren Sie also Ihre Anwendung und verwenden Sie eine Art Repository. Dann verwenden Sie eine beliebige Technik, um diese Repositorys zu implementieren. Auf diese Weise haben Sie eine vollständig entkoppelte Lösung, bei der Sie jede gewünschte Datenzugriffsschicht anschließen können.

In dieser Datenzugriffsschicht können Sie Ihr eigenes ORM oder Linq für SQL verwenden. Dies spielt keine Rolle, solange die Datenzugriffsschicht die von Ihnen definierten Repositorys implementiert.

— Tomas Jansson
quelle

1

Sofern Sie nicht möchten, dass Ihre "Geschäftslogikschicht" Transaktionen und die Abfrageleistung berücksichtigt, ist weiterhin eine DAL erforderlich.

LINQ macht die Abfragedeklaration zu einem Entwurfsprozess (auch bekannt als Compiler-geprüft).

LINQ-Abfrageanbieter (wie LinqToSql und LinqToEntities) konvertieren diese deklarierten Abfragen weiterhin zur Laufzeit in SQL-Text. Dann führt das DBMS weiterhin die Interpretation von Laufzeitabfragen, die Generierung von Laufzeitabfrageplänen usw. durch.

Dies ist nur ein kleiner Teil des DAL.

— Amy B.
quelle