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

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?

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.

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.

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.

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.

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.

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.