Business-Logik: Datenbank oder Application Layer

StackOverflow https://stackoverflow.com/questions/119540

  •  02-07-2019
  •  | 
  •  

Frage

Die uralte Frage. Wo sollten Sie Ihre Geschäftslogik setzen, in der Datenbank als gespeicherte Prozeduren (oder Pakete) oder in der Anwendung / Middle-Tiere? Und was noch wichtiger ist, warum?

Angenommen Datenbank Unabhängigkeit ist kein Ziel.

War es hilfreich?

Lösung

genug von der Business-Logik in der Datenbank, um sicherzustellen, dass die Daten konsistent und korrekt ist.

Aber keine Angst, die auf einer anderen Ebene einige diese Logik duplizieren die Benutzerfreundlichkeit zu verbessern.

Andere Tipps

Wartbarkeit des Codes ist immer ein großes Anliegen bei der Bestimmung, wo die Geschäftslogik gehen sollte.

Integrierte Debugging-Tools und leistungsfähigeren IDEs im Allgemeinen mittleren Ebene Code leichter als der gleiche Code in einer gespeicherten Prozedur machen zu halten. Solange es keinen wirklichen Grund anders ist, sollten Sie mit Business-Logik in Ihrer mittleren Schicht / Anwendung und nicht in gespeicherten Prozeduren starten.

Allerdings, wenn Sie kommen, um Reporting und Data Mining / Suche, gespeicherte Prozeduren können oft die bessere Wahl. Dies ist dank der Kraft der Datenbanken Aggregation / Filterfunktionen und die Tatsache, Sie Verarbeitung zu halten sind sehr die die Quelle der Daten schließen. Aber das kann nicht sein, was die meist ohnehin klassische Business-Logik betrachten.

Bei sehr einfachen Fällen können Sie Ihre Business-Logik in gespeicherten Prozeduren setzen. Normalerweise sogar die einfachen Fälle sind in der Regel kompliziert im Laufe der Zeit zu bekommen. Hier sind die Gründe, warum ich nicht Geschäftslogik in der Datenbank setzen:

Inbetriebnahme der Business-Logik in der Datenbank fest koppelt es an die technische Umsetzung der Datenbank. eine Tabelle ändern führt, dass Sie wieder eine Menge der gespeicherten Prozeduren ändern, um eine Menge von zusätzlichen Fehlern und zusätzlichen Tests verursacht wird.

In der Regel hängt die UI auf Business-Logik für Dinge wie Validierung. Setzt man diese Dinge in der Datenbank wird eine enge Kopplung zwischen der Datenbank führen und die Benutzeroberfläche oder in verschiedenen Fällen dupliziert die Validierungslogik zwischen diesen beiden.

Es wird noch hart mehrere Anwendungen arbeiten auf der gleichen Datenbank zu haben. Änderungen für eine Anwendung, werden andere zu brechen. Dies kann schnell in einen Albtraum. So ist es nicht wirklich skaliert werden.

Mehr praktisch SQL ist keine gute Sprache Business-Logik in einer verständlichen Art und Weise umzusetzen. SQL ist für Satz basierten Operationen, aber es fehlt Konstrukte für „Programmierung im großen“ es ist schwer, große Mengen an gespeicherten Prozeduren zu halten. Moderne OO-Sprachen sind besser geeignet und flexibler für diese.

Das bedeutet nicht, dass Sie nicht gespeichert Procs und Ansichten verwenden können. Ich denke, es ist manchmal eine gute Idee ist, eine zusätzliche Schicht von Stored Procedures und Views zwischen den Tabellen und Anwendung (en) zu setzen, die beide zu entkoppeln. Auf diese Weise können Sie das Layout der Datenbank ändern, ohne externe Schnittstelle ändern so dass Sie die Datenbank unabhängig Refactoring.

Es ist wirklich an Ihnen, , solange Sie konsistent sind .

Einen guten Grund, es in Ihrer Datenbank-Ebene zu setzen: Wenn Sie ziemlich sicher sind, dass Ihre Kunden werden nie ihre Datenbank ändern Back-End.

Ein guter Grund, es in der Anwendungsschicht zu setzen: Wenn Sie mehr Persistenz-Technologien für Ihre Anwendung sind Targeting

.

Sie sollten auch berücksichtigen, Kernkompetenzen. Sind Ihre Entwickler hauptsächlich Anwendungsschicht Entwickler, oder sind sie in erster Linie DBA-Typen?

Während es sicherlich Vorteile sind die Business-Logik auf der Anwendungsschicht haben, ich möchte darauf hinweisen, dass die Sprachen / Frameworks scheinen häufiger zu ändern, um die Datenbanken dann.

Einige der Systeme, die ich unterstütze, ging durch die folgenden UIs in den letzten 10-15 Jahren: Oracle Forms / Visual Basic / Perl-CGI / ASP / Java Servlets. Das einzige, was nicht ändern -. Die relationale Datenbank und gespeicherte Prozeduren

Zwar gibt es keine richtige Antwort - es auf das Projekt in Frage abhängt, würde ich den Ansatz befürwortete in „ Domain Driven Desig n“von Eric Evans. Bei diesem Ansatz wird die Geschäftslogik in einer eigenen Ebene getrennt - die Domänenschicht - die auf der Oberseite der Infrastrukturschicht sitzt (en) - die Datenbank-Code enthalten könnte, und unterhalb der Anwendungsschicht, die die Anforderungen in die Domänenschicht sendet für die Erfüllung und wartet auf eine Bestätigung ihrer Fertigstellung, effektiv die Anwendung der Fahrt.

Auf diese Weise wird die Geschäftslogik in einem Modell erfaßt, die mit denen, die das Geschäft von technischen Fragen beiseite verstehen diskutiert werden können, und es sollte es einfacher machen, Änderungen zu isolieren, in dem Geschäft selbst regiert, die technische Fragen der Umsetzung und der Ablauf der Anwendung, die mit dem Unternehmen (Domäne) Modell interagiert.

Ich empfehle das oben Buch zu lesen, wenn Sie die Chance bekommen, da es ziemlich gut ist, kann zu erklären, wie das reine Ideal tatsächlich in der realen Welt der realen Code und Projekte angenähert werden.

Datenbank Unabhängigkeit, die die Fragesteller in diesem Fall als Gegenleistung ausgeschlossen ist, ist das stärkste Argument Logik aus der Datenbank für die Aufnahme. Das stärkste Argument für Datenbank-Unabhängigkeit ist für die Fähigkeit, Software-Unternehmen mit ihrer eigenen Präferenz für einen Datenbank-Backend zu verkaufen.

Daher würde ich das Hauptargument für die Aufnahme betrachtet gespeicherte Prozeduren aus der Datenbank nur ein kommerzieller zu sein, nicht technische Natur. Es kann aus technischen Gründen, aber es gibt auch technische Gründe für die es dort zu halten -. Leistung, Integrität und die Möglichkeit, mehr Anwendungen zu ermöglichen, die gleiche API zum Beispiel zu verwenden,

Unabhängig davon, ob SP zu verwenden, auch stark von der Datenbank beeinflusst wird, dass Sie gehen zu verwenden. Wenn Sie Datenbank aus Rücksicht nehmen Unabhängigkeit dann wirst du haben sehr unterschiedliche Erfahrungen mit T-SQL oder mit PL / SQL.

Wenn Sie Oracle verwenden, eine Anwendung zu entwickeln, dann PL / SQL ist eine offensichtliche Wahl als Sprache. Es ist sehr eng mit den Daten verbunden ist, kontinuierlich in jedem relase verbessert, und jedes anständiges Entwicklungs-Tool wird zu integratePL / SQL Entwicklung mit CVS oder Subversion, etc. zu jagen.

Oracle Web-basierte Application Express Entwicklungsumgebung sogar 100% mit PL / SQL gebaut wird.

Alles, was die Datenintegrität auswirkt, muss auf Datenbankebene gesetzt werden. Andere Dinge neben der Benutzeroberfläche setzen oft Daten in, aktualisieren oder löschen Daten aus der Datenbank einschließlich der Importe, Massenupdates ein Preisschema, Hot Fixes zu ändern, usw. Wenn Sie die Regeln, um sicherzustellen, immer gefolgt, legen Sie die Logik in Verzug und löst.

Dies ist nicht zu sagen, dass es keine gute Idee ist es, auch in der Benutzeroberfläche (warum Informationen plagen, sendet, dass die Datenbank nicht akzeptieren), aber diese Dinge zu ignorieren, in der Datenbank Katastrophe vor Gericht ist .

Wenn Sie die Datenbankunabhängigkeit benötigen, werden Sie wahrscheinlich wollen, dass alle Logik Ihres Unternehmens in der Anwendungsschicht setzen, da die verfügbaren Standards in der Anwendungsebene sind weit häufiger als diejenigen, auf die Datenbankebene.

Wenn jedoch die Datenbankunabhängigkeit ist nicht die # 1-Faktor und die Skill-Set Ihres Teams umfasst starke Datenbank Fähigkeiten, dann die Business-Logik in der Datenbank setzen kann sich als die beste Lösung sein. Sie können Ihre Anwendung Leute tun anwendungsspezifische Dinge und Ihre Datenbank Leute sicherstellen, dass alle Anfragen haben fliegen.

Natürlich gibt es einen großen Unterschied zwischen der Lage, eine SQL-Anweisung zusammen zu werfen und „starke Datenbank Fähigkeiten“, die - wenn Ihr Team mit dem ehemaligen näher ist als die letztere dann in der Anwendung der Logik setzen mit einem der überwintert dieser Welt (oder Ihr Team ändern!).

Nach meiner Erfahrung in einer Enterprise-Umgebung haben Sie eine einzelne Zieldatenbank und Fähigkeiten in diesem Bereich - in diesem Fall alles setzen Sie in der Datenbank können. Wenn Sie im Geschäft der Verkauf von Software sind, werden die Datenbanklizenzkosten Datenbankunabhängigkeit machen der größte Faktor, und Sie werden alles implementieren Sie in der Anwendungsebene können.

Ich hoffe, das hilft.

Es ist heute möglich, senden Sie Ihren gespeicherte Prozedur Code Subversion und diesen Code mit guter Werkzeugunterstützung zu debuggen.

Wenn Sie gespeicherte Prozeduren verwenden, die SQL-Anweisungen kombinieren können Sie die Menge des Datenverkehrs zwischen der Anwendung reduzieren und die Datenbank und die Anzahl der Datenbankaufrufe reduzieren und große Performance-Gewinne gewinnen.

Wenn wir den Aufbau in C # begonnen haben wir die Entscheidung nicht gespeichert Procs zu verwenden, aber jetzt sind wir mehr und mehr Code gespeichert Procs bewegen. Vor allem der Stapelverarbeitung.

Allerdings verwenden keine Trigger, Verwendung gespeichert Procs oder besser Pakete. Auslöser Sie verringern Wartbarkeit.

Setzen Sie den Code in der Anwendungsschicht in einer DB-unabhängigen Anwendung führen wird.

Manchmal ist es besser, Stored Procedures aus Leistungsgründen verwendet werden.

Es (wie üblich) ist abhängig von den Anforderungen der Anwendung.

Das einzige, was in einer Datenbank geht, ist Daten.

Stored Procedures sind ein Alptraum in Sachen Wartung. Sie sind nicht die Daten, und sie gehören nicht in der Datenbank. Die endlose Koordination zwischen Entwicklern und DBA ist wenig mehr als organisatorische Reibung.

Es ist schwer, gute Version Kontrolle über gespeicherte Prozeduren zu halten. Der Code außerhalb der Datenbank ist sehr einfach zu installieren - wenn Sie denken, dass Sie die falsche Version haben Sie nur UP einen SVN tun (vielleicht eine Installation) und Ihre Anwendung zurück in einen bekannten Zustand. Sie haben Umgebungsvariablen, Verzeichnis Links und viele Umwelt Kontrolle über die Anwendung.

Sie können mit einfachen PATH Manipulationen haben Variante Software, die für verschiedene Situationen (Ausbildung, Prüfung, QA, Produktion, kundenspezifische Erweiterungen etc., etc.)

Der Code in der Datenbank ist jedoch viel schwieriger zu verwalten. Es gibt keine richtige Umgebung - kein „PATH“, Verzeichnis Links oder andere Umgebungsvariablen - jede brauchbare Kontrolle über das, was Software zur Verfügung zu stellen verwendet wird; Sie haben eine permanente, global gebunden Reihe von Anwendungssoftware in der Datenbank fest, an die Daten verheiratet.

Trigger ist noch schlimmer. Sie sind beide eine Wartung und ein Debugging-Alptraum. Ich sehe nicht, welches Problem sie lösen; sie scheinen eine Art zu arbeiten um schlecht gestaltete Anwendungen zu sein, wo jemand die verfügbaren Klassen (oder Funktionsbibliotheken) zu verwenden, nicht richtig gestört werden könnte.

Während einige Leute die Leistung Argument überzeugend finden, ich habe noch nicht genug Benchmark-Daten zu sehen, mich zu überzeugen, dass gespeicherte Prozeduren sind alle schnell, dass. Jeder hat eine Anekdote, aber niemand hat Side-by-Side-Code, wo die Algorithmen sind mehr oder weniger das gleiche.

[In den Beispielen, die ich gesehen habe, war die alte Anwendung ein schlecht konzipiertes Chaos; wenn die gespeicherten Prozeduren geschrieben wurden, wurde die Anwendung neu gestaltet. Ich denke, die Designänderung mehr Wirkung als der Plattformwechsel hatte.]

Die Business-Logik sollte in der Anwendung / mittlere Schicht als erste Wahl gestellt werden. Auf diese Weise kann es in Form eines Domänenmodells ausgedrückt werden, in der Quellcodeverwaltung platziert werden, mit zugehörigem Code (Refactoring) geteilt oder kombiniert werden, usw. Es gibt Ihnen auch eine Datenbank Herstellerunabhängigkeit.

Objektorientierte Sprachen sind auch viel ausdrucksvoller als gespeicherte Prozeduren, so dass Sie besser und leichter in Code beschreiben, was soll geschehen.

Die einzigen Gründe Code in gespeicherten Prozeduren zu platzieren sind: wenn so einen erheblichen und notwendigen Leistungsvorteil ergibt tun oder wenn das gleiche Geschäft Code muss von mehreren Plattformen (Java, C #, PHP) ausgeführt werden. Selbst wenn mehrere Plattformen verwenden, gibt es Alternativen wie Web-Services, die besser geeignet sein könnten Funktionalität zu teilen.

Die Antwort in meiner Erfahrung liegt irgendwo auf einem Spektrum von Werten in der Regel bestimmt, wo Ihre Organisation Fähigkeiten liegen.

Das DBMS ist ein sehr mächtiges Tier, die richtige oder falsche Behandlung bedeutet, wird großen Nutzen oder große Gefahr bringen. Leider zu viele Organisationen, wird primäre Aufmerksamkeit auf die Programmierung Personal bezahlt; dbms Fähigkeiten, vor allem Abfrage Entwicklungskompetenz (im Gegensatz zu Verwaltungsgegen) werden vernachlässigt. Welche durch die Tatsache verschärft, dass die Fähigkeit dbms Fähigkeiten zu bewerten, auch wahrscheinlich fehlt.

Und es gibt wenige Programmierer, die ausreichend verstehen, was sie über Datenbanken nicht verstehen.

Daraus ergibt sich die Popularität von suboptimalen Konzepte, wie Active Aufzeichnungen und LINQ (in einigen offensichtlichen Tendenz zu werfen). Aber sie sind wahrscheinlich die beste Antwort für solche Organisationen.

Beachten Sie jedoch, dass hoch skalierten Organisationen neigen dazu, viel mehr Aufmerksamkeit auf effektive Nutzung des Datenspeichers zu zahlen.

Es gibt keine eigenständige richtige Antwort auf diese Frage. Es hängt von den Anforderungen Ihrer Anwendung, die Vorlieben und Fähigkeiten Ihrer Entwickler und die Phase des Mondes.

Die Geschäftslogik ist in der Anwendungsebene gestellt werden und nicht in der Datenbank. Der Grund dafür ist, dass eine Datenbank gespeicherte Prozedur immer dependen wird Sie auf dem Datenbankprodukt verwenden. Dieser Bruch ist einer der Vorteile des Drei-Schichten-Modells. Sie können nicht ohne weiteres auf eine andere Datenbank ändern, wenn Sie eine zusätzliche gespeicherte Prozedur für diese Datenbank Produkt. manchmal auf der anderen Seite, macht es Sinn, Logik in eine gespeicherte Prozedur zur Performance-Optimierung zu setzen.

Was ich sagen möchte, ist Business-Logik in die Anwendungsebene gebracht werden soll, aber es gibt Ausnahmen (vor allem Performance-Gründen)

Bussiness-Anwendung 'Schichten' sind:

1. User Interface

Dies implementiert die Business-User-Ansicht von h (ist / er) Job. Es verwendet Begriffe, die der Benutzer kennt.

2. Verarbeitung

Dies ist, wo Berechnungen und Datenmanipulation passieren. Jede Geschäftslogik, die Änderung von Daten beinhaltet ist implementiert hier.

3. Datenbank

Dies könnte: eine normalisierte sequentielle Datenbank (die Standard-SQL-basierte DBMS); eine OO-Datenbank zu speichern Objekte der Business-Daten Verpackung; etc.

Was geht Wo

zu den oben genannten Schichten bekommen Sie die notwendige Analyse und Design zu tun. Dies würde darauf hindeuten, wo Business-Logik am besten umgesetzt werden würde: Datenintegritätsregeln und Gleichzeitigkeit / Echtzeit-Ausgaben Daten-Updates in Bezug auf normalerweise so nah wie möglich an die Daten umgesetzt werden würde, genau wie würde Felder berechnet, und das ist ein guter Zeiger zu gespeicherten Prozeduren / Trigger, wo die Datenintegrität und Transaktionskontrolle unbedingt erforderlich ist.

Die Geschäftsregeln, die Bedeutung und Nutzung der Daten würden zum größten Teil in der Verarbeitungsschicht implementiert werden, beteiligt, sondern auch im User-Interface wie die Arbeit des Benutzers Fluss erscheinen würde - die Verknüpfung der verschiedenen Verfahren in irgendeiner Reihenfolge das spiegelt die Aufgabe des Benutzers.

Imho. gibt es zwei widerstreitende Interessen mit der Entscheidung, wo die Geschäftslogik in einer relationalen Datenbank-gestützte Anwendung geht:

  • Wartbarkeit
  • Zuverlässigkeit

Re. Wartbarkeit:. Um für eine effiziente zukünftige Entwicklung zu ermöglichen, die Geschäftslogik gehört in dem Teil Ihrer Anwendung, die am einfachsten zu debuggen und Versionskontrolle ist

Re. Zuverlässigkeit: Wenn es erhebliche Gefahr von Inkonsistenzen, Geschäftslogik gehört in der Datenbank-Ebene. Relationale Datenbanken können entworfen werden, um Einschränkungen für Daten zu überprüfen, z.B. NULL-Werte in bestimmten Spalten nicht erlaubt, usw. Wenn ein Szenario entsteht in Ihrer Anwendung Design, bei dem einige Daten in einem bestimmten Zustand sein muss, die zu komplex ist, mit diesen einfachen Einschränkungen auszudrücken, kann es Sinn machen, einen Trigger oder etwas ähnliches zu verwenden, in der Datenbank-Ebene.

Trigger ist ein Schmerz auf dem neuesten Stand zu halten, vor allem, wenn Ihre Anwendung auf Client-Systemen laufen sollte man nicht einmal Zugang verfügen. Aber das bedeutet nicht, dass es unmöglich ist, sie zu verfolgen oder sie aktualisieren. S.Lott Argumente in seiner Antwort, dass es ein Schmerz und Ärger sind vollständig gültig, ich werde zweitens, dass und haben auch dort gewesen. Aber wenn Sie diese Beschränkungen beachten, wenn Sie zuerst Ihre Datenschicht entwerfen und verzichten auf Trigger und Funktionen für alles andere als die absoluten Notwendigkeiten es ist überschaubar.

In unserer Anwendung, die meisten Business-Logik in die Anwendung des Modells Schicht enthalten, z.B. eine Rechnung weiß, wie sich um von einem bestimmten Umsatz zu initialisieren. Wenn ein Bündel von verschiedenen Dingen der Reihe nach für eine komplexe Reihe von Veränderungen, wie dies geändert werden, können wir sie in einer Transaktion aufrollen Konsistenz zu erhalten, statt für eine gespeicherte Prozedur entscheiden. Die Berechnung der Summen usw. sind alle mit Methoden in der Modellschicht erfolgen. Aber wenn wir etwas für die Leistung oder Einfügen von Daten in eine ‚Änderungen‘ Tabelle von allen Clients verwendet, um denormalize müssen, um herauszufinden, welche Objekte sie müssen in ihrer Sitzung Cache ablaufen, verwenden wir Trigger / Funktionen in der Datenbank-Ebene eine neue Zeile einzufügen und sendet eine Benachrichtigung (Postgres hören / notify Sachen) von diesem Trigger.

unsere App auf dem Gebiet für etwa ein Jahr Nachdem verwendet von Hunderten von Kunden jeden Tag, das einzige, was ich ändern würde, wenn wir von Grund auf neu beginnen waren würde unser System zu entwerfen, für Datenbankfunktionen zu schaffen (oder gespeicherte Prozeduren jedoch mögen Sie sie) mit Versionierung und Updates, um sie im Auge von dem get-go nennen.

Zum Glück haben wir einige Systeme haben den Überblick über Schemaversionen zu halten, so dass wir gebaut etwas obendrein zu kümmern Datenbank-Funktionen zu ersetzen. Es hätte uns einige Zeit gespeichert, wenn wir die Notwendigkeit in Betracht gezogen hatte, obwohl sie von Anfang an zu ersetzen.

Natürlich ändert sich alles, wenn Sie außerhalb des Bereichs von RDBMS in Tupel-Speichersysteme wie Amazon SimpleDB und Googles BigTable Schritt. Aber das ist eine andere Geschichte:)

Wir haben viele Business-Logik in gespeicherten Prozeduren - es ist nicht ideal, aber oft ist es eine gute Balance zwischen Leistung und Zuverlässigkeit.

Und wir wissen, wo es ist, ohne durch acre von Lösungen und Code-Basis suchen zu müssen!

Die Skalierbarkeit ist auch sehr wichtiger Faktor für die Geschäftslogik in der Mitte oder App Schicht pusing als zur Datenbank layer.It zu verstehen, dass DatabaseLayer ist nur für die Interaktion mit Datenbank nicht zu manipulieren, die zu oder von der Datenbank zurückgegeben wird.

Ich erinnere mich an einen Artikel irgendwo gelesen, dass darauf hingewiesen, dass ziemlich gut kann alles auf einer Ebene sein, einen Teil der Business-Logik, und so ist die Frage sinnlos.

Ich denke, das gegebene Beispiel die Anzeige einer Rechnung am Bildschirm ist. Die Entscheidung, einen überfälligen eine in rot zu markieren ist eine unternehmerische Entscheidung ...

Es ist ein Kontinuum. IMHO der größte Faktor ist die Geschwindigkeit. Wie kann u diesen Sauger aufstehen und so schnell wie möglich laufen, während nach wie vor wie Wartbarkeit gute Mieter der Programmierung haften, Leistung, Skalierbarkeit, Sicherheit, Zuverlässigkeit usw. Oft SQL ist die knappste Art und Weise etwas auszudrücken und geschieht auch zu sein die meisten performant viele Male, mit Ausnahme von String-Operationen usw., aber das ist, wo Ihre CLR Procs helfen können. Meine Überzeugung ist, großzügig um Geschäftslogik zu streuen wo auch immer Sie das Gefühl, es am besten für das Unternehmen bei der Hand ist. Wenn Sie eine Reihe von Anwendungsentwickler haben, die ihre Hosen scheißen, wenn bei SQL suchen, dann sollen sie ihre App-Logik verwenden. Wenn Sie wirklich eine leistungsstarke Anwendung mit großen Datensätzen erstellen möchten, setzen Sie so viel Logik in der DB wie Sie können. Feuer Ihre DBA und geben Entwicklern die größtmögliche Freiheit über ihre Dev-Datenbanken. Es gibt keine eine Antwort oder beste Werkzeug für den Job. Sie haben mehrere Werkzeuge so Experten auf allen Ebenen der Anwendung werden und Sie werden bald feststellen, dass Sie viel mehr Zeit mit dem Schreiben nette consise expressive SQL Ausgaben sind, wo die Anwendungsschicht zu anderen Zeiten gerechtfertigt und verwenden. Für mich schließlich ist die Anzahl der Codezeilen zu reduzieren, was zur Einfachheit führt. Wir haben konvertierten nur eine SQL-reiche Anwendung mit gerade einmal 2.500 Zeilen von App-Code und 1000 Zeilen von SQL zu einem Domänenmodell, das jetzt 15500 Zeilen von App-Code und 2500 Zeilen von SQL hat zu erreichen, was der ehemaligen SQL reich App tat. Wenn Sie eine 6-fache Erhöhung des Code rechtfertigen können als „vereinfacht“, dann rechts weiter gehen.

Dies ist eine große Frage! Das fand ich, nachdem ich hatte bereits eine simliar Frage , aber dies ist präziser. Es kam als Ergebnis einer Designänderung Entscheidung, dass ich nicht bei der Herstellung beteiligt war.

Im Grunde, was ich mir wurde gesagt, dass, wenn Sie Millionen von Zeilen von Daten in Ihrer Datenbank-Tabellen haben, dann schauen Sie sich die Geschäftslogik in Stored Procedures und Trigger setzen. Das ist, was wir jetzt tun, eine Java-Anwendung in gespeicherte Prozeduren für Wartbarkeit Umwandlung als der Java-Code verworren geworden war.

Ich habe diesen Artikel an: die Business-Logik-Kriege Der Autor hat auch die Millionen Zeilen in einer Tabelle Argument, das ich interessant fand. Er fügte hinzu, auch Business-Logik in JavaScript, das ist Client-Seite und außerhalb der Geschäftslogikebene. Ich hatte nicht gedacht, darüber vor, obwohl ich Sie Javascript für die Validierung seit Jahren verwendet haben, um zusammen mit Server-Seite Validierung.

Meine Meinung ist, dass Sie die Geschäftslogik in der Anwendung / mittlere Ebene als Faustregel wollen, aber Fälle nicht Rabatt, wo es Sinn macht, sie in die Datenbank zu stellen.

Ein letzter Punkt, gibt es eine andere Gruppe, wo ich derzeit gerade arbeite, dass massive Datenbank-Arbeit für die Forschung tut und die Menge der Daten, die sie zu tun haben immens ist. Doch für sie sie haben keine Business-Logik in der Datenbank selbst, sondern in der Anwendung / Middle-Tiere halten. Für ihr Design war die Anwendung / mittlere Ebene der richtige Ort für sie, so würde ich nicht die Größe von Tabellen als einzige Designbetrachtung verwendet werden.

Die Geschäftslogik wird in der Regel durch Objekte und die verschiedenen Sprachkonstrukte von Kapselung, Vererbung und Polymorphismus und verkörpert. wenn eine Bankanwendung um Geld Zum Beispiel ist vorbei, kann es ein Geld-Typ sein, der das Geschäfts Elemente definiert, was „Geld“ ist. Dies im Gegensatz eine primitive Dezimalzahl mit Geld zu repräsentieren. Aus diesem Grunde gut gestaltete OOP ist, wo die „Business Logik“ lebt, nicht streng in jeder Schicht.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top