Dies ist so etwas wie ein persönlicher heiliger Grundsatz: Was immer das Back-End tun kann, soll es auch tun. Angesichts dieser Vorliebe ist die Abneigung dagegen verständlich, Datenbank-Logik in das Front-End zu verlagern.
Warum so unerschütterlich an diesem Prinzip festhalten? Mehrere unterschiedliche Front-End-Applikationen können eine einzige Datenbank ansprechen – das können Websites, Visual Studio-Applikationen, Delphi-Applikationen et cetera sein. In dem Maße, wie Code vom Back-End zum Front-End verlagert wird, muss man die Instruktionen von einem Front-End zum anderen duplizieren und übersetzen. Das ist ganz hübsch, wenn man sich entschließt, innerhalb von Visual Studio .NET zu bleiben, aber was ist, wenn man selbst oder der Arbeitgeber andere Vorstellungen hat? Oder was ist, wenn man daran interessiert ist, diese Logik auf andere Datenbanken zu portieren?
Diese Sicht ist nicht unumstritten. Es gibt Entwickler, die argumentieren, dass bestimmte Applikationen und Situationen ad hoc dynamisch konstruierte Abfragen erfordern. Man kann dagegenhalten, dass diese Situationen einfach nicht gründlich genug analysiert wurden, doch könnte man sich in dieser Hinsicht auch überzeugen lassen. Untersucht man also die andere Sicht und geht davon aus, dass sie richtig ist: Es gibt bestimmte Situationen, in denen der einzig richtige Ansatz ist, das Front-End ein gültiges SQL-Statement erzeugen, den Code vor SQL-Injection schützen und das Statement dann an die Datenbank-Engine übergeben zu lassen.
Nimmt man weiter an, dass es unabhängig von der Richtigkeit beider Positionen zahlreiche Entwickler gibt, die ihre SQL-Instruktionen lieber für das Front-End als für das Back-End entwickeln würden. Genau für diese Gruppe von Entwicklern ist LINQ am interessantesten. Je nachdem, inwieweit man dem Grundsatz zustimmt, dass das Back-End tun soll, was es tun kann, wird man diese Verlagerung in Richtung Front-End beunruhigend finden oder nicht.
Neueste Kommentare
3 Kommentare zu Ist LINQ die Zukunft der Datenbank-Entwicklung?
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Auf die Anwendung schauen
auf die ewige Frage, wo die Anwendungslogik am besten plaziert werden sollte helfen auch die Dogmen des Autors nicht. Schließlich gibt es zahlreiche Anwendungen, die auf bestehende Datenbanken in Unternehmen Rücksicht nehmen müssen. Hier bestimmt letztendlich der Anwender welche Datenbank eingesetzt wird und die Anwendung muss mit unterschiedlichen existierenden Datenbanken zusammenarbeiten. Nach 15 Jahren Datenbankentwicklung bin ich sicher, dass es keinen Stein der Weisen gibt. Die Anwendung und deren voraussichtliche Entwicklung bestimmt, wo ich die Logik plaziere, sonst gar nichts.
AW: Auf die Anwendung schauen
Ist super alt; aber bei den alten News kann man am besten die Idee dahinter verstehen.
Merkwürdiger Artikel
Schon alt, aber dennoch:
Ich kann das Problem des Authors nicht nachvollziehen? BackEnd? FrontEnd? Was soll diese künstlich herbeigeredete Begründung?
Es ist m.E. unerheblich, ob man seine SQLs z.B. via ADO.NET direkt gegen die Datenbank schickt oder ein integriertes Sprachkonstrukt verwendet. Die Prinzipien ändern sich damit nicht!
Kernpunkt ist wie die resultierenden Daten weitergegeben werden. Und da ist natürlich jedem Entwickler, der zumindest eine 3-tier Anwendungen entwickelt hat klar, daß es ohne Probleme möglich ist LINQ in eine 3-tier Umgebung zu integrieren.
Inzwischen gibt es auch einige LINQ erweiterungen z.B. auf codeplex.com welche die Ausführung von LINQ auf Remotemaschinen und deren Parallelisierung ermöglichen. Auch ein nettes Tool – über den Sinn lässt sich streiten.