Was genau besteht aus „Business Logic“ in einer Anwendung?

Question

Ich habe unzählige Male gehört, dass wir „Geschäftslogik nicht mit anderem Code vermischen sollten“ oder solche Aussagen machen.Ich denke, jeder einzelne Code, den ich schreibe (ich meine Verarbeitungsschritte), besteht aus Logik, die sich auf die Geschäftsanforderungen bezieht.

Kann mir jemand sagen, was genau aus Geschäftslogik besteht?Wie kann es von anderem Code unterschieden werden?Gibt es einen einfachen Test, um festzustellen, was Geschäftslogik ist und was nicht?

Answer 1

Definieren Sie einfach in einfachem Englisch, was Sie tun.Wenn Sie geschäftliche Dinge sagen, wie „die leiden lassen“, „das Geld stehlen“ oder „diesen Teil der Erde zerstören“, sprechen Sie von der geschäftlichen Ebene.Um es klarzustellen: Hier finden Sie Dinge, die Sie begeistern.

Wenn Sie sagen „zeigen Sie dies hier“, „zeigen Sie jenes nicht“, „machen Sie es schöner“, sprechen Sie von der Präsentationsebene.Das sind die Dinge, die Ihre Designer begeistern.

Wenn Sie Dinge wie „Speichern“, „Aus Datenbank abrufen“, „Aktualisieren“, „Löschen“ usw. sagen.Sie sprechen von der Datenschicht.Dies sind die Dinge, die Ihnen sagen, was Sie um jeden Preis für immer behalten sollten.

Answer 2

Es ist wahrscheinlich einfacher, zunächst einmal zu sagen, was ist nicht Geschäftslogik.Datenbank- oder Festplattenzugriff ist keine Geschäftslogik.Die Benutzeroberfläche ist keine Geschäftslogik.Netzwerkkommunikation ist keine Geschäftslogik.

Für mich sind Geschäftslogik die Regeln, die beschreiben, wie ein Unternehmen funktioniert, nicht wie eine Softwarearchitektur funktioniert.Auch die Geschäftslogik neigt dazu, sich zu ändern.Beispielsweise kann es eine geschäftliche Anforderung sein, dass jedem Kunden eine einzige Kreditkarte mit seinem Konto zugeordnet ist.Diese Anforderung kann sich ändern, sodass Kunden mehrere Kreditkarten besitzen können.Theoretisch sollte es sich lediglich um eine Änderung der Geschäftslogik handeln, andere Teile Ihrer Software sind davon nicht betroffen.

Das ist also Theorie.In der realen Welt (wie Sie festgestellt haben) verbreitet sich die Geschäftslogik tendenziell in der gesamten Software.Im obigen Beispiel müssen Sie wahrscheinlich eine weitere Tabelle zu Ihrer Datenbank hinzufügen, um die zusätzlichen Kreditkartendaten zu speichern.Sie müssen auf jeden Fall die Benutzeroberfläche ändern.

Die Puristen sagen, dass die Geschäftslogik immer völlig getrennt sein sollte und wäre daher sogar dagegen, Tabellen mit den Namen „Kunden“ oder „Konten“ in der Datenbank zu haben.Im Extremfall würde man am Ende ein unglaublich generisches und unmöglich zu wartendes System erhalten.

Es gibt definitiv ein starkes Argument dafür, den Großteil Ihrer Geschäftslogik zusammenzuhalten, anstatt sie im gesamten System zu verschmieren, aber (wie bei den meisten Theorien) müssen Sie in der realen Welt pragmatisch sein.

Answer 3

Ich glaube, Sie verwechseln Geschäftslogik mit Ihren Anwendungsanforderungen.Es ist nicht dasselbe.Wenn jemand die Logik seines/ihres Geschäfts erklärt, ist das etwa so:

„Wenn ein Benutzer einen Artikel kauft, muss er Lieferinformationen angeben.Die Informationen werden mit xyz-Regeln validiert.Danach erhält er eine Rechnung und sammelt Punkte, wodurch er x % Rabatt für die y Angebote erhält“ (Entschuldigung für das schlechte Beispiel)

Wenn Sie diese Geschäftsregeln implementieren, müssen Sie sekundäre Anforderungen berücksichtigen, z. B. wie die Informationen dargestellt werden, wie sie dauerhaft gespeichert werden, wie die Kommunikation mit Anwendungsservern erfolgt, wie der Benutzer die Rechnung erhält und so weiter.All diese Anforderungen sind nicht Teil der Geschäftslogik und sollten von dieser entkoppelt werden.Auf diese Weise können Sie Ihren Code mit weniger Aufwand anpassen, wenn sich die Geschäftsregeln ändern.Das ist Fakt.

Manchmal reproduziert die Präsentation einen Teil der Geschäftslogik, hauptsächlich bei der Validierung von Benutzereingaben.Es muss aber auch in der Geschäftslogikschicht vorhanden sein.In anderen Situationen ist es aus Leistungsgründen erforderlich, einige Geschäftslogiken in die Datenbank zu verschieben.Dies wird von Martin Fowler diskutiert Hier.

Answer 4

Um die Dinge auf eine einzige Zeile zu vereinfachen ...
Geschäftslogik wäre Code, der nicht von einem bestimmten UI-/Implementierungsdetail abhängt bzw. sich nicht mit diesem ändert.Es handelt sich um eine Codedarstellung der Regeln, Prozesse usw.die durch das zu modellierende Geschäft definiert sind bzw. es widerspiegeln.

Answer 5

Mir gefallen die BLL+DAL-Namen der Ebenen nicht, sie sind eher verwirrend als klärend.
Nennen Sie es DataServices und DataPersistence.Dies wird es einfacher machen.

Dienste manipulieren CRUDs auf Persistenzebene (Erstellen, Lesen, Aktualisieren, Löschen)

Answer 6

Für mich, " Geschäftslogik „besteht aus allen Entitäten, die auf die Problemdomäne anwendbare Daten darstellen, sowie aus der Logik, die darüber entscheidet, „was mit den Daten geschehen soll“.

Es sollte also eigentlich aus „Datentransport“ (nicht Zugriff) und „Datenmanipulation“ bestehen.Eigentlich sollte der Datenzugriff (Dinge, die in die Datenbank gelangen) in einer anderen Ebene erfolgen, ebenso wie der Präsentationscode.

Answer 7

Wenn es etwas über Dinge wie Formular, Schaltfläche usw. enthält.Es handelt sich nicht um eine Geschäftslogik, sondern um eine Präsentationsebene.Wenn es Persistenz für eine Datei oder Datenbank enthält, handelt es sich um DAL.Alles dazwischen ist Geschäftslogik.In Wirklichkeit wird alles, was nicht zur Benutzeroberfläche gehört, manchmal als „Geschäftslogik“ bezeichnet, aber es sollte etwas sein, das die Problemdomäne betrifft, nicht die Haushaltsführung.

Answer 8

Geschäftslogik ist reine Abstraktion, sie existiert unabhängig von der Materialisierung/Visualisierung der Daten vor Ihrem Benutzer und unabhängig von der Persistenz der zugrunde liegenden Daten.

In der Steuervorbereitungssoftware wäre beispielsweise eine Aufgabe der Geschäftslogikklassen die Berechnung der geschuldeten Steuern.Sie wären nicht dafür verantwortlich, Berichte anzuzeigen oder eine Steuererklärung zu speichern und abzurufen.

---

@Lars, „Dienste“ impliziert eine bestimmte Architektur.