Das Unternehmen, für das ich arbeite, verwendet derzeit Stored Procedures (im MsSQL-Server-Backend) als Business Logic Layer. Die eigentliche Business-Logik-DLL ruft nur die sProcs auf und verwaltet im Wesentlichen die Benutzeroberfläche (Ereignisse, Datenbindung usw.)
Ich denke, im Setup stimmt etwas nicht, obwohl ich mir nicht sicher bin, wie ich es meinen Kollegen erklären soll. Übrigens, das System funktioniert.
Sind die "Best Practices" an meinem Arbeitsplatz falsch? Oder übertreibe ich das einfach?
GaiusSensei - es ist vollkommen in Ordnung, so zu arbeiten, solange die Geschäftsdomäne in der Lage ist, mit seismischen Verschiebungen in den Geschäftspraktiken umzugehen. Ich denke, dass die Debatte zwischen SPs und BLL-Dlls immer noch weit verbreitet ist, und zweifellos wird es in diesem Thread auf beiden Seiten viel geben. Aus meinen eigenen Erfahrungen mit einer Reihe von Projekten in den letzten 10 Jahren, hier sind meine Beobachtungen, die den BLL dll Ansatz unterstützen:
Die Liste geht weiter, aber das sind meine Top-of-the-Head-PROS für die Annahme eines BLL-Ansatzes.
Ich schaue auf die vielen Spins auf diesem einen Blick:)
Jim
[edit] - Ich würde auch hinzufügen, dass diese BLL keine UI-Informationen ausgeben sollte, außer (wie du es erwähnst), um Ereignisse etc. jeder UI-Schicht zu übermitteln (relevant für das Zielgerät - Browser / mobiles Gerät / Factory) sollte die BLL referenzieren und mit den Daten ein eigenes 'thang' machen. Ich würde weiter hinzufügen, dass unterhalb der BLL Ihre DAL-Schicht wäre. Diese Ebene könnte als 1-1-Referenz für den zugrunde liegenden Datenspeicher betrachtet werden.
Wir machen das.
Das liegt daran, dass wir Szenarien unterstützen, in denen Benutzer sich mit der Datenbank verbinden, indem sie andere Programme als die vorgesehene Software verwenden (wie SQL Management Studio, osql und Excel).
Wenn Sie sich direkt mit einer Datenbank verbinden, die nicht mehr als ein Datenspeicher ist, können Sie alles durcheinander bringen, da es keine Regeln gibt, die Sie aufhalten könnten. Diese Regeln gibt es nur innerhalb des Programms, das diese Datenbank verwendet, und wenn Sie dieses Programm nicht verwenden, können Sie die Berechtigungen Ich-kann-schreiben-für-diese-Tabelle verwenden, um dumme (oder spaßige) Dinge zu tun.
> Wenn Sie nur zum Ausführen gespeicherter Prozeduren berechtigt sind, können Sie dies nicht tun.
Ich persönlich denke, es ist ein besserer Ansatz.
Es klingt wie Ihre Business-Schicht ist eigentlich die Datenschicht und Ihre Anwendung hat keine Business-Schicht, aber ich schweife ab ...
Best Practices werden überschätzt und verändern sich mit der Zeit. Wenn das, was sie tun, funktioniert und sie damit zufrieden sind, dann kann nicht viel getan werden.
Ich kann Ihnen nicht sagen, an wie vielen Projekten ich beteiligt war, wo der neue Typ an Bord kommt, und denkt, dass die aktuelle Architektur geändert werden muss. Ich habe es ein paar Mal selbst gemacht. Es ist kein guter Ort zu sein. Der Status Quo wird Sie bis zum Ende kämpfen. Wenn Sie wirklich das aktuelle System ändern wollen, bauen Sie eine gewisse Glaubwürdigkeit auf. In 3 bis 6 Monaten beginnen Sie, bessere Wege vorzuschlagen, um einen Teil der bestehenden Infrastruktur anzugehen. Wenn Sie die aktuelle Architektur wirklich nicht mögen, dann verlassen Sie das Unternehmen.
Die Bewerbung wurde mit den besten Absichten geschrieben. Die ursprünglichen Entwickler waren mit Zeit, Erfahrung und Technologie eingeschränkt.
Anwendungen wie die von Ihnen beschriebene sind gute Lernmöglichkeiten. Notiere die fehlerhaften Punkte, lerne von ihren Erfolgen. Du wirst erstaunt sein, was du lernst.
(Ich habe das "subjective" -Tag hinzugefügt)
Ich bevorzuge die Verwendung gespeicherter Prozeduren, außer in kleinen Apps, die ich herauspicke, weil das Herumspielen mit gespeicherten Prozeduren ein wenig mehr Zeit in Anspruch nimmt.
Christopherous 5000: Sie können weiterhin Komponententests mit gespeicherten Prozeduren durchführen
Ich stimme der Antwort auf diese beiden ähnlichen Fragen zu:
Kommt darauf an.
Es hängt davon ab, was Sie Geschäftslogik nennen.
Bestimmte Dinge müssen in der Datenbank durchgesetzt werden - insbesondere alles, wo ein anderer Prozess Annahmen über die Art dessen, was die Datenbank präsentiert, haben wird.
Wenn alle Benutzer der Datenbank annehmen, dass wenn der letzte Ableger eines Rechners deaktiviert ist, der Status des Rechners geändert werden muss, dann muss dies in der DB erzwungen werden - entweder in einem SP, der der einzige Weg ist um die Operation oder einen Trigger oder eine Einschränkung oder etwas durchzuführen. Dies ist die Art der Sache - Low-Level-Geschäftslogik, die wirklich kritische Datenintegritätslogik auf der Geschäftsebene ist - die in der Datenbank in Ordnung ist.
Die Geschäftslogik auf höherer Ebene passt nicht in die Datenbank - wenn beispielsweise ein Patient seinen letzten Termin storniert und auf eine Rückrufliste gehen muss - das ist kein Problem mit der Datenintegrität - alle Anrufer des Systems gehen nicht davon aus Patienten ohne Termine müssen auf der Rückrufliste stehen.
Die Unterscheidung ist subtil und deshalb haben Menschen Schwierigkeiten mit der "Geschäftslogik" in der Datenbank. Ich empfehle nur Dinge, von denen angenommen wird, dass die Datenbank schützt und am Datenbankperimeter allen Benutzern der Datenbank in der Datenbank implementiert ist - diese Geschäftslogik liegt unterhalb der DAL-Schicht und ist Teil des grundlegenden Datenbankentwurfs. Ich befürworte immer noch in traditionellen Architekturen ein Business-blindes DAL darüber und ein echtes BLL darüber.
Nachdem das gesagt wurde, ist es sicherlich möglich, wenn die DAL wirklich trivial ist, dass SP Ihre Geschäftslogik auf höherer Ebene in der Datenbank speichert, und wenn Sie das tun, ist es nicht so klar, welche Dinge auf niedriger Ebene sind und welche sind High-Level (es sei denn, Sie haben zwei Datenbanken, eine auf der anderen gebaut - das ist nicht unbedingt eine schreckliche Idee). Sie haben effektiv einen Teil Ihrer Geschäftslogik in SQL anstelle einer herkömmlichen Client-App geschrieben.
Das bedeutet nicht unbedingt, dass Ihre Layer zu eng gekoppelt sind oder Sie eine schlechte Architektur haben. Wie bei jedem System muss die Sprachauswahl für verschiedene Layer nicht unbedingt auf ein Architekturproblem hinweisen. Nur wenn Sie sich die Layer ansehen, können Sie feststellen, ob Sie ein Architekturproblem haben.
Ich würde sagen, dass Stored Procedures für Unit-Testing und Refactoring fast genauso wenig geeignet sind wie Business-Layer-Logik in zB .net / java. Ich würde so viel wie möglich Logik aus der DB heraushalten, die Hauptausnahme wäre inhärent gesetzt basis Operationen, wo ein DBMS würde sich auszeichnen.
Ich denke, dass gespeicherte Prozeduren als Teil Ihrer Geschäftslogik in Ordnung sind. Ich glaube nicht, dass Sie Ihre gesamte Geschäftslogik in einer DLL haben müssen. Wenn Sie jedoch eine Business-Schicht haben, die die Benutzeroberfläche verwaltet, denke ich, dass Sie die UI-Verwaltung von der Business-Schicht mit einer Art Framework trennen müssen. Die Trennung sollte funktional sein, Daten nicht in Ihre gespeicherten Prozeduren oder Ihre Geschäftslogik einbetten und umgekehrt. Ich denke auch, dass Sie, wenn Sie andere Programme haben, wie Excel oder Reporting, auf die Daten zugreifen, die sie über eine diskrete Datenquelle, einen Webservice oder was auch immer erhalten sollten.
Ich benutze, um auf Client-Server-Systemen mit Mainframes zu arbeiten, wo Sie echte Trennung von drei Schichten und echte Knochen-Inflexibilität erhalten. Moderne Anwendungen müssen in der Implementierung ein wenig offener sein und Geschäftsregeln, insbesondere für die Validierung, auf allen Ebenen haben. Das bedeutet nicht, dass Ihr Designmodell keine Trennung haben kann. Geschäftsregeln wie "ist leer oder Wochentag" müssen nur über die Benutzeroberfläche, die Business-Schicht und die Daten implementiert werden.
Wenn das, was Sie haben, funktioniert, dann stellen Sie sich vor, wie Sie damit arbeiten können.
Tags und Links sql-server stored-procedures