Was nützt ein Business Logic Layer (BLL)?

14

Beim Nachlesen bewährter Verfahren für Datenbankanwendungen bin ich häufig auf Befürworter sogenannter "Business Logic Layers" gestoßen, und ich versuche zu entscheiden, ob es für mein Projekt am besten ist, eines zu verwenden (es ist ein kleines persönliches Projekt). Mein Problem liegt in der Tatsache, dass mir nichts für die BLL einfällt, was die DAL nicht bereits verarbeiten kann (Abfragen ausführen und Ergebnisse Objekten zuordnen), sodass meine BLL die DAL nur aufruft, ohne selbst etwas zu tun.

Vielleicht irre ich mich genau darüber, was der DAL auch tun sollte. Aber unabhängig davon, welche Art von Funktionalität sollte von einer BLL in einer Datenbankverwaltungsanwendung erwartet werden?

Andrew Arnold
quelle
Klingt nach Effizienz vs. Flexibilität / Code-Wiederverwendungsdilemma.
Job
@Job - Ja, irgendwie, zumal es sich um eine kleine App handelt, die (noch) keine Chance auf Wiederverwendung von Code bietet. Zum Teil wird jedoch auch versucht, die bestmögliche Vorgehensweise zu verwenden.
Andrew Arnold
Ich habe alle positiv bewertet, weil sie alle großartige Antworten sind. leider kann ich nur eine annehmen.
Andrew Arnold

Antworten:

10

Für meine kleineren Anwendungen beginnt meine BLL normalerweise als Durchleitung zum DAL. Ich bin damit einverstanden. Wenn ich Geschäftsregeln "entdecke", stelle ich sie in die BLL. Ich finde auch eine Menge Dinge, die in der BLL benötigt werden, wenn ich meine Tests schreibe. Für meine eigenen persönlichen Apps erstelle ich die Geschäftsregeln, und die BLL ist immer noch dort, wo ich sie abgelegt habe. Für mich ist die BLL etwas, das mit der Zeit wächst. Je länger ich an einem Projekt gearbeitet habe, desto größer ist die BLL.

Würde ich in Betracht ziehen, BLL und DAL für ein kleines Projekt zu kombinieren? Ich könnte, abgesehen von der Tatsache, dass ich DAL-Technologien ungefähr so ​​oft ändere, wie ich Frisuren ändere, und ich möchte etwas, um meinen Client-Code davon zu isolieren.

Marcie
quelle
2
Ich habe meine Frisur seit 20 Jahren nicht mehr geändert. Ich würde es hassen, meine DAL-Technologie so oft zu ändern, wie ich Frisuren ändere.
Erik Funkenbusch
3
Manche Leute aktualisieren ihre DAL auch nur alle 20 Jahre!
Marcie
4
Gute Antwort. Es ist üblich, dass kleine Projekte wirklich nicht viel in die BLL zu stecken haben. Es ist auch üblich, dass kleine Projekte größer werden, und wenn Sie nicht mindestens eine BLL-Shell installiert haben, wird sich die wachsende Menge an Logik entweder in der Präsentationsebene oder in der DAL ansammeln wünschenswert.
Carson63000
5

Die BLL würde Dinge behandeln, die Teil der Geschäftsdomäne sind, nicht Teil der Datenbank und nicht Teil der Benutzeroberfläche (normalerweise). Verwenden Sie beispielsweise das Alter eines Kunden, um zu bestimmen, ob er Anspruch auf einen speziellen Seniorenrabatt hat. Die DAL sollte dies nicht tun, sie sollte einfach die Kundendaten abrufen und sie dann mit den Rabattdaten speichern, nachdem die BLL ihre Arbeit erledigt hat. Der DAL sollte sich mehr auf CRUD konzentrieren. In kleinen Anwendungen können sich die beiden Probleme überschneiden.

FrustratedWithFormsDesigner
quelle
Tatsächlich ist dies ein Teil des Problems beim Versuch, "Ebenen" oder "Ebenen" wie diese zu isolieren. Oft muss etwas Ebenen überqueren, weil es in dieser anderen Ebene besser geeignet ist. Ein gutes Beispiel sind SQL-Abfragen mit integrierter Geschäftslogik. Beispielsweise könnte Ihre Altersberechnung vollständig in der SQL-Ebene (oder der ORM-Ebene) effizienter durchgeführt werden.
Erik Funkenbusch
2
@Mystere Man Effizienter ist subjektiv. Dieser Kommentar bedeutet, dass Sie wissen, was im Front-End stattfindet. Es ist sehr statisch in der Natur. Verwenden Sie SQL-Abfragen, um die Daten sicher zu optimieren, aber es gibt eine feine Linie, wenn Sie beginnen, eine Benutzeroberfläche mit dem Back-End zu verknüpfen.
Aaron McIver
1
@ Mystere Man: In der Tat kann es. Und es ist oft wahr, dass Dinge von einer Schicht zur nächsten "durchbluten". Die wahre Kunst besteht darin , sie zu trennen und getrennt zu halten. Ich weiß, es ist nicht immer einfach ...
FrustratedWithFormsDesigner
1
Und Boom , vorzeitige Optimierung hebt den hässlichen Kopf! Ich kann mir nur schwer vorstellen, dass ein einfacher Datumsvergleich einen solchen Engpass darstellt, dass es gerechtfertigt ist, eine Geschäftsregel in die DAL zu verschieben. Wartbarkeit sollte auch ein Ziel sein, nicht nur Geschwindigkeit.
TMN
5

Andrew,

Business Logic Layers erhalten Sie, wenn Sie eine domänengetriebene Entwicklung durchführen und sich auf die Kernaktivitäten der Domäne konzentrieren. Wenn Sie die Präsentationsschicht (GUI, Web) und die Infrastrukturschicht (DB, Netzwerkkonnektivität usw.) entfernen, verfügen Sie über die Kernaktivitäten, die zu Ihrer Domain gehören, z. B. die Einzahlung von Geld auf ein Bankkonto. Wenn Sie nun Ihre Business-Schicht modelliert und von Präsentation und Infrastruktur isoliert haben, können Sie sie problemlos für andere Zwecke wie das Internet oder mobile Geräte portieren. Es ist eine saubere Art, über Entwicklung nachzudenken, und nach allem, was ich gesehen habe, wird es leider nicht so ernst genommen.

Ich würde empfehlen, Eric Evans - Domain Driven Design in die Hände zu bekommen, ein gutes Buch, das es rechtfertigt, die Entwicklungsanstrengungen auf die Domain zu konzentrieren. Zugegeben, es ist auf halbem Weg ein bisschen trockenes Lesen, aber es baut Momentum auf und hat einige starke Überzeugungen darüber, was Entwickler mit heutigen Systemen falsch machen.

Trostloser Planet
quelle
4

Es gibt nichts, was besagt, dass Sie eine bestimmte Anzahl von Ebenen oder Schichten haben MÜSSEN. Es hängt alles von der Komplexität Ihres Projekts ab. Werfen Sie einen Blick auf viele der MVC-Beispiel-Apps, wie das Nerd-Dinner oder den Plattenladen. Alle verwenden zwei Ebenen, da dies für Anwendungen mit sehr geringer Verarbeitungslogik keinen Sinn ergibt.

Selbst wenn Ihre App klein ist, kann es von Vorteil sein, die Datenschicht über eine dritte Schicht, die normalerweise eine Geschäftsschicht ist, von der Präsentationsschicht weg zu abstrahieren. Auf diese Weise können Sie Änderungen an einem einzelnen Ort vornehmen und nicht auf der gesamten Präsentationsebene.

Angenommen, Sie möchten Ihr ORM von Linq zu SQL zu Entity Framework (oder nhibernate) ändern. Es wird wahrscheinlich einfacher sein, es in der Business-Ebene zu ändern als in Ihrer Präsentations-Ebene, da die Präsentation eng mit dem Präsentationsmodell verknüpft ist.

Wenn Sie MVC verstehen, das heißt .. Model View Controller, können Sie sich Ihre Anwendungsarchitektur in ähnlichen Begriffen vorstellen. Das Modell ist analog zu Ihrer Datenebene, die Präsentationsebene ist die Ansicht und die Business-Ebene ist der Controller.

Erik Funkenbusch
quelle
4

Ergänzung der Antwort von Desolate Planet zu Domain Driven Design:

Schauen Sie sich auch die Onion-Architektur an , die sehr gut zu den Domain Driven Design-Konzepten passt.

Beachten Sie, dass die Business Logic-Ebene der Kern der Zwiebel ist und jede Infrastrukturebene (wie die Datenzugriffsebene) ihre externen Abhängigkeiten aufweist. Dies erleichtert das Testen erheblich, da Sie in der Lage sein sollten, jede externe Infrastrukturabhängigkeit zu verspotten und Ihre Domänenlogik vollständig zu testen.

Meiner Meinung nach: In der Business Logic Layer lebt die "pure conceptual solution". Der Rest sind nur Details zur Implementierung der Infrastruktur.

Einige Anwendungen benötigen diese Art von Architektur jedoch möglicherweise nicht. Wenn alle Ihre Anwendungen Dataset-CRUD-Operationen sind, ist Ihre "reine konzeptionelle Lösung" möglicherweise praktisch leer, und Sie benötigen lediglich ein Frontend für die Datenbankbearbeitung. In diesem Fall sollten Sie sich wahrscheinlich besser nur auf die DAL- und UI-Ebenen konzentrieren.

Sergio Acosta
quelle
1

Die Antwort auf diese Frage lautet (IMHO): "Kann ich meine DAL vollständig ersetzen und muss keinen meiner Geschäftslogikcodes umschreiben"?

Stellen Sie es sich wie Ihre Präsentationsebene vor - es ist durchaus üblich, die Benutzeroberfläche durch eine andere zu ersetzen. Eine leistungsfähige Desktop-Benutzeroberfläche wird gegen einen Webclient ausgetauscht, der gegen eine iPhone-App ausgetauscht wird. Für BLL / DAL ist dies nicht so üblich, da sie nie wirklich ausgetauscht werden, außer vielleicht für etwas sehr Ähnliches (z. B. eine durch eine MySQL-Datenbank ersetzte SQLServer-Datenbank), aber wenn Sie sich vorstellen, dass Sie Ihre DB in einen verteilten Speicher ändern mussten Bei einem Dienst, auf den über eine API zugegriffen wurde, erhalten Sie möglicherweise eine klarere Vorstellung davon, wo sich die Ebenen treffen.

gbjbaanb
quelle