Ist LINQ die Zukunft der Datenbank-Entwicklung?

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.