Moderne Praktiken für Anwendungen, die auf gespeicherten Prozeduren basieren

Question

Ich arbeite in einer ziemlich großen und alten Lösung, die viele Einstiegspunkte für verschiedene Arten von Clients hat, mit Websites für den öffentlichen Zugriff, Websites für den internen Zugriff, einigen Websites und Webdiensten für den Zugriff von Partnerunternehmen usw.

All diese Anwendungen verwenden verschiedene (Microsoft-basierte) Technologien, wie Classic ASP, ASP.NET WebForms, MVC 3, ASMX, DTSX usw. Der Code hat keinen Standard und viele Programmierer ohne Erfahrung mit der Codebasis und im Geschäfthaben ihren eigenen Weg codiert.

Der zentrale Punkt aller Anwendungen ist eine SQL Server-Datenbank mit unzähligen gespeicherten Prozeduren, die alle Geschäftsregeln implementieren.Die Anwendungen sind normalerweise nur eine Shell für die Datenbank.Der Datenzugriff erfolgt ohne Framework oder ORM (mit reinem ADO.NET, normalerweise alles neu schreiben, vom Herstellen einer Verbindung bis zum Durchlaufen eines Datenlesers für jede Methode, Funktion oder was auch immer).

Was sind die modernsten Best Practices zum Erstellen einer produktiven Datenzugriffsschicht basierend auf gespeicherten Prozeduren?

Aus betriebswirtschaftlichen Gründen können wir die älteren Anwendungen nicht umschreiben (dafür zahlt der Kunde nicht, dafür ist der Arbeitsumfang intern zu groß).Wir können auch kein ORM von Drittanbietern verwenden (die Architekten sind aus "Sicherheitsgründen" dagegen).Die Verbesserungen müssen also eher Refactorings sein.

Answer 1

Ah, der Klassiker "1000 Line Business Rule Stored Procedure, keine Unit-Tests, Ball of Mud-Anwendung".

Es ermöglicht Produktionsoptimierungen, da Sie sich einfach beim SQL-Server anmelden und ein wenig SQL-Code aktualisieren können und Ihre App nicht erneut bereitstellen müssen.

Nun, im Grunde ist mein Rat, zunächst keine Geschäftsregeln für neue Funktionen in der Schicht der gespeicherten Prozeduren zu platzieren.

Alles, was Sie von Grund auf neu schreiben, das auf die Datenbank zugreift, und vorausgesetzt, Sie können keine ORM-Tools verwenden, legen Sie Ihre CRUD-SQL nur in gespeicherte Prozeduren ab.Behalten Sie Ihre Geschäftsregeln in Ihrem Code bei und stellen Sie sicher, dass er Unit-Tests durchgeführt wird.

Um dies zu erreichen, müssen Sie keine ORM-Tools verwenden (obwohl die Ausrede aus "Sicherheitsgründen" für mich nach BS klingt).

Wenn mehrere Anwendungen auf eine gemeinsame Datenbank zugreifen, sollten Sie die Einführung einer gemeinsamen Serviceschicht in Erwägung ziehen, um mehreren Anwendungen auf konsistente Weise gemeinsame Funktionen bereitzustellen.