| 

.NET C# Java Javascript Exception

5
Darf man Stored Procdures (und damit Logik) in einer Datenbank verwenden, wenn man eine auf Schichten basierende Softwareanwendung schreibt?

  • SPs reduzieren die Weiterentwickelbarkeit (Evolvability) und Wartbarkeit (Maintainability)
  • Der Nutzen einer DAL besteht in der Entkopplung von Business Logik und Datenbank. Die SPs widersprechen diesem Prinzip.
  • Die Testbarkeit von Business Logik ist schwierig. Eine Änderung der SPs führt schnell zu Änderungen im Interface.
  • Die Sicherheit der SPs auf einzelene Tabellen kann auch durch eine Sicherheitschicht abgedeckt werden.
  • Und auch die deutlich bessere Performance der SPs ist IMO häufig ein Trugbild.

Sind Stored Procedures böse?
Nennt Eure PROs und CONs.
09.02.2012
judgy 3,0k 1 1 8
judgy 3,0k 1 1 8
"und lasst uns." - was?
Und wäre diese Frage nicht in der Lounge besser aufgehoben?
Matthias Hlawatsch 09.02.2012
Habs korrigiert.
Ich kann mit dem Begriff *Lounge* nichts anfangen.
Für Foren gibt es anderen Alternativen.
judgy 09.02.2012
@judgy Die "Lounge" (mir hätte "Kaffeeküche" auch besser gefallen) ist der hier noch relativ neue, links oben in der Navi erreichbare Bereich für Diskussionen. Der Vorteil dort ist, dass die zeitliche Reihenfolge der Beiträge erhalten bleibt, was es erleichtert, eine sich auf vorhergehende Beiträge zu beziehen. Deine Fragestellung schien mir eine solche Art der Diskussion nahezulegen.
Matthias Hlawatsch 09.02.2012
@Matthias, ich habe mir die Kaffeeküche nach Deinem letzten Kommentar einmal angesehen.
Aber will mich meine Frage in der Kaffeeküche diskutieren? Theoretisch müsste man die Frage hier bei Fragen und Antworten stellen, dann 'streitet' man sich in der Küche beim Kaffee (in der Tat gab/gibt es hier in der Firma großen Streit zwischen Entwicklern und DBAs) und schliesslich bringt man dann hier die Anworten Ja, aber .. und Nein, aber ..
Insofern war mein korrigerter Satz oben "Nennt Eure PROs und CONs und lasst uns die Argumente hier zusammefassen"
judgy 09.02.2012
3 Antworten
4
Wieso widerspricht es dem Schichtenmodell? BL und DAL sind immer noch getrennt, die DAL ruft halt nur noch die SPs auf, ist damit aber weiterhin für den Datenbankzugriff zuständig.

Und wieso kann man es schlechter warten oder weiterentwickeln? Weiterentwickeln verstehe ich noch so halb, eine zentral genutzt SP kann man natürlich nicht einfach für die eigenen Zwecke anfassen. Dann passt halt einfach die SP nicht zum Programm und man muss was eigenes entwickeln.
Aber Wartbarkeit? Ob du jetzt die SP in deinem Projekt anfasst oder den SQL-String/LINQ/Whatever in deinem Projekt, da sehe ich keinen großen Unterschied.

Die BL kannst du weiterhin genau so einfach testen, egal was der DAL darunter macht. Deshalb hast du ja die Schichten.
Ob eine Änderung der SP in einer Änderung im UI führt, das hängt dann sehr vom eigentlichen Programm ab. Aber wenn es dazu führen würde, dann würde es wohl auch dazu führen, wenn du den SQL-String in deinem Projekt hast. Also eigentlich wieder kein Unterschied.

Ein Vorteil ist sicherlich, dass die SP zentral vorhanden sind und man von mehreren Applikationen darauf zugreifen kann, ohne dass man extra Libraries dafür erstellen muss. Dafür bedarf es natürlich auch ein paar Regeln, sonst kann das schnell zu einer mittelgroßen Katastrophe führen, wenn einfach jemand mal z.B. die Parameter der SP ändert.

Zu Sicherheit und Performance möchte ich nicht viel sagen. Irgendwie mach ich dir auch eine SP so langsam, dass jedes SELECT * FROM xyz von einem Handy schneller ist. Da kommt es dann also mehr auf den Code und den Entwickler an.

Mein Fazit
Stored Procedures haben schon ihren Sinn und Zweck. Man muss sie eben dann einsetzen, wenn es auch sinnvoll ist sie einzusetzen. Es ist sicherlich falsch jedes Stückchen SQL aus dem Code zu entfernen und eine SP daraus zu machen, genau so falsch kann es aber auch sein, jedes SQL-Statement stur als LINQ in den Code zu packen (oder wie immer man es im Code umsetzen möchte).
09.02.2012
Feroc 1,2k 2 9
4
Zum lesen von Daten würde ich Functionktionen bevorzugen. Direkt die Statements in dem DAL zu vertraten führt bei Komplexen Datenmodellen mit mehren hundert Tabellen (so wie es in großen Unternehmen vorkommen kann) schnell zu dopplungen von ähnlichen Statements.

Ein Beispiel wie ein Statement dann im DAL aussehen könnte:
--Liste alle Verträge und Anträge einer Person und gibt die Basisdaten zum selbigen aus
select
V.Vertragsnummer, V.Jahresbeitrag, V.IsVertrag, V.IsAntrag,
P.VName [VN_Vorname], P.NName [VN_Nachname]
from dbo.fkVertraege(/*Person ID:*/ 123456, /* Filter: */ 1 /*Standard-Verträge*/ + 2 /*Stanrd-Anträge*/) V
join dbo.fkPersondaten(V.Versicherungsnehmer) P


Storage Procedures würd ich dann zur Datenmanipulation verwenden. Also hinzufügen, löschen und modifizieren von Daten.

Dadurch wird eine strickte Trennung zwischen dem Datenzugriff und der Logik der Datenspeicherung erreicht. Gerade wenn die einzelnen Daten in verschiedenen Tabellen gespeichert werden müssen kann ich die Struktur beliebig verändern ohne alle stellen des DAL die damit in Berührung kommen ändern zu müssen.

--Person hinzufügen
exec @PersonId = dbo.spAddPerson 'Name', 'Vorname'

--Person updaten
exec dbo.SetPerson @PersonId, 'Geburtsdatum'

--Person löschen
exec dbo.DelPerson @PersonId
09.02.2012
Floyd 14,6k 3 9
4
Ich finde, die Antwort hängt stark davon ab, wie Du Deine Schichten aufbaust und was Du in den SPs machst.

Unter dem Blickwinkel von Geheimnisprinzip und Trennung der Zuständigkeiten soll die Geschäftslogik an einem Ort bleiben. Gemeint ist damit Logik, die unabhängig davon existiert, wo die Daten gespeichert werden bzw. ob sie überhaupt gespeichert werden. Solche Logik hat in SPs nur dann etwas verloren, wenn der komplette Business Layer als SPs in der Datenbank läuft (eine eher seltene, aber theoretisch durchaus mögliche Form einer Schichtenarchitektur). Das ist die Grundregel, die in hohem Maße zu Wartbarkeit, Weiterentwickelbarkeit und Testbarkeit beiträgt. Abweichungen davon würde ich nur in gut begründeten Ausnahmefällen zulassen - also z.B., wenn durch Messung nachgewiesen wird, dass für einen bestimmten Anwendungsfall die Performance nicht ausreicht, sie mit einer SP erreicht werden könnte und kein besseres Mittel zur Verfügung steht.

Logik, die unmittelbar mit der Datenspeicherung zu tun hat - die also überflüssig werden würde, wenn Du die Daten gar nicht oder mit einer anderen Technologie speichern würdest - ist in SPs ganz gut aufgehoben. Floyd hat ein gutes Beispiel für einen solchen Fall gegeben.
09.02.2012
Matthias Hlawatsch 13,2k 4 9
/unterschreib
Jaksa 09.02.2012

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH