Ist das Zeitalter der Domänenlogik in Datenbanken vorbei? [geschlossen]

Ich bin kürzlich auf diese Meinung aus dem Jahr 2016 gestoßen , dass es in der Datenbank immer noch Argumente für Domänenlogik gibt.

Ich fand das total veraltet. Ich frage mich nur, ob der Typ noch in den 90ern lebt oder ob das wirklich wahr sein kann. Legacy-Systeme beiseite legen.

Was ist mit der Domänenlogik in der Datenbank aufgrund von Sicherheitsanforderungen? Ist das wirklich eine Sache zu tun?

Programmierer scheinen heutzutage sehr dogmatisch zu denken, besonders wenn sie die Gedanken lesen, die andere Leute in ihren Blogs schreiben.

Nehmen wir zum Beispiel Bob Martins Clean Coding-Blog. Als allgemeine Beobachtung finde ich Bob Martins Schriften ziemlich klar und klar, so dass es mich verblüfft, dass die Leute ständig durch die Dinge verwirrt werden, die er schreibt, wie zum Beispiel die SOLID-Prinzipien. Sie werden aufgehängt, was eine "Einzelverantwortung" sein sollte oder warum eine Klasse gegen Liskovs Prinzipien verstößt, wenn sie wahrscheinlich einfach danach streben sollten, besseren Code zu schreiben und zuerst etwas Erfahrung zu sammeln, damit das, was sie einlesen Blogs haben einen gewissen Kontext.

Grundsätzlich sagen Sie, dass die Datenbank Tabellen und Daten enthalten sollte, und das ist alles, was sie enthalten sollte. Aber Datenbanken sind einzigartig geeignet, um bestimmte Dinge zu tun, in denen ... Datenbanken gut sind.

Der Artikel zitiert diese Dinge:

• Datenintegrität und -validierung (z. B. null und eindeutige Einschränkungen)
• Sicherheit auf Zeilenebene
• Schreiben einer API mit gespeicherten Prozeduren
• Salden berechnen
• Stellen der Datenbankfragen (dh Abfragen und Berichten)
• Vermeiden von ORM-Problemen wie N + 1

als geeignete Dinge zum Einfügen in die Datenbank. Ich stimme ihm zu.

Gründe, warum Sie Geschäftslogik (im Allgemeinen) nicht in eine Datenbank einfügen:

• Lieferantenbindung
• Ihre Datenbank ist nicht die zentrale Behörde
• Ihr Team denkt nicht relational
• Minderwertiges Werkzeug.

Diese Dinge gelten jedoch im Allgemeinen nur für jene Techniken, Werkzeuge und Schulungen, für die die Datenbank nicht eindeutig geeignet ist.

Wie bei jeder anderen Technik in der Softwareentwicklung kommt es darauf an. Sie bewerten Ihre Alternativen und treffen Ihre Entscheidung auf der Grundlage der Ihrer Meinung nach bestmöglichen Vorgehensweise für Ihre spezifische Anwendung.

Das Zeitalter von Pferd und Buggy ist vorbei, aber Sie können immer noch Buggy-Peitschen kaufen.

Warum? Wenn Autos schneller und billiger zu warten sind und ihre Vernachlässigung keine Besuche der humanen Gesellschaft hervorruft, warum gibt es dann immer noch Pferdewagen?

Denn manchmal haben Sie neben den populären Gründen auch andere Gründe, etwas zu tun.

Was Sie lernen sollten, ist, warum Domänenlogik in einer Datenbank Probleme verursacht und was möglicherweise jeder daraus machen könnte. Dann entscheide dich selbst.

Meine persönliche Meinung:

In der Domänenlogik geht es um Verhalten. In Datenbanken geht es um Persistenz, Beziehungen und Daten. Wenn Sie es so sehen, sollten Geschäftsregeln nicht in der Datenbank enthalten sein.

Auf der anderen Seite, wer, sagte die Datenbank konnte kein Verhalten haben? Ich habe Office-Datenbanken mit Filemaker erstellt. Die Leute nennen es eine Datenbank, aber es ist auch eine ganze Anwendungsentwicklungsumgebung. Alles nahtlos in eine integriert und als Datenbank bezeichnet.

Wizdom findet man normalerweise zwischen extremen Ansichten. Ich habe keinen Zweifel, dass auch zur Arbeit gebracht werden könnte. Wenn man versucht, die Mitte zu finden, ist es verlockend, einfach der Herde zu folgen. Ich werde hier davor warnen.

Ein System, das die Domänenlogik in der Datenbank hält, kann gut funktionieren. Ein System, das die Domänenlogik aus der Datenbank heraushält, kann gut funktionieren. Ein System, das Domänenlogik an beiden Orten mischt, wird mich verrückt machen. Ich werde nicht wissen, wo ich neues Verhalten anbringen soll. Ich bin mir nicht sicher, wo ich altes Verhalten finden kann.

Wenn Sie sich immer noch nicht entscheiden können, werfen Sie eine Münze und treffen Sie ihre Entscheidung als Evangelium für ein bestimmtes Projekt. Soweit ich das beurteilen kann, weiß diese Münze genau wie jeder andere, was am besten ist.

Ich hatte einen Fall, in dem das Lösen in der Geschäftsschicht ein echter Leistungskiller gewesen wäre.

Unser Anwendungs-OO-Sicherheitskonzept besteht aus Rollen UND Gruppen. Und beide sind rekursive Strukturen. Wir haben eine gespeicherte Prozedur geschrieben, die die Berechtigung für einen Benutzer für ein Domänenobjekt auflöst.

Es gibt wirklich weniger Bedürfnisse, auf die Datenbanklogik zurückzugreifen. Aber in diesem Fall habe ich mich für diesen Weg entschieden. Aber was Sie immer beachten müssen: Sie geben die Abstraktion auf. Sobald Sie Geschäftslogik in der Datenbank haben, fällt es Ihnen schwer, Ihre Persistenzschicht zu ändern. Sei also sehr sehr vorsichtig.