Geschäftslogik ( Java ) einfach erklärt?
Hallo kann mir vllt jemand die Geschäftslogik bei der Java Programmierung einfach erklären? Aus der Wikipedia Defintion werde ich nicht schlau.
4 Antworten
Früher hat man mit Programmierung einfach das Geschäftsproblem gelöst und das ganze Programm - abgesehen von ein bisschen Ein-/Ausgabe - war die Geschäftslogik.
Dafür war das ganze aber auch monolithisch und hat nur mit bestimmten Ein-/Ausgabegeräten und mit bestimmten Datenbanken in einer speziellen Ablaufumgebung funktioniert. Im Extremfall erforderte schon eine andere Bildschirmauflösung auf dem Ausgabegerät eine Programmänderung an allen Teilen.
Daher hat man das ganze in mehrschichtige Architekturen aufgesplittet, wobei jede Schicht nur eine ganz spezielle Aufgabe zu erfüllen hatte. Dabei ist es dann egal, welches Ausgabegerät verwendet wird - die Geschäftslogik bleibt ja dieselbe.
Das hat aber auch zur Folge, dass sich ein anteilsmäßig großer Teil des Programms gar nicht mehr mit Geschäftslogik beschäftigt, sondern mit der Kommunikation zwischen den Schichten. Da ist eine Menge programminterner Selbstverwaltung im Spiel - und das grenzt kann man von der "eigentlichen" Aufgabe, der "Geschäftslogik", ab.
Ja, aber manche Programmiersprachen sind schon stark darauf angelegt, "größere Flexibilität" zu ermöglichen - auf Kosten von "mehr administrativem Overhead".
Nehmen wir mal als Geschäftslogik "Gib 'Hallo Welt!' aus!". Dann haben wir in BASIC:
PRINT "Hallo Welt!"
...aber in Java
class Hallo {
public static void main( String[] args ) {
System.out.print("Hallo Welt!");
}
}
Das heißt die einzelnen Schichten und die damit verbundenen Aufgaben sind die Geschäftslogik?
Die Schichten dienen der Geschäftslogik, aber sie sind es nicht.
Beispiel: Du willst Jacken verkaufen. Das geht nach Flohmarkt-Art (Tisch auf dem Marktplatz und Jacken drauflegen) oder nach Kaufhaus-Art (Gebäude mit Rolltreppen und komplexe Verkaufsorganisation). Die Geschäftslogik ist dabei dieselbe - Jacke dem Kunden geben und Geld dafür bekommen.
Das Kaufhaus dient dem Verkaufen - man kann auf diese Weise vielleicht viel mehr verkaufen und auch völlig andere Sachen - aber es ist nicht das eigentliche Geschäft.
Im realen Leben würde man das organisatorisch wahrscheinlich auch trennen: Spezialisten, die das Kaufhaus-Gebäude in Betrieb halten und andere Spezialisten, die dem Kunden etwas verkaufen, also das eigentliche Kerngeschäft.
Bei der Programmierung ist es nicht anders - man trennt die Geschäftslogik - das Kerngeschäft - vom Rest.
Stell dir vor du wurdest beauftragt ein Softwareprogramm zu erstellen, welches eine bestimmte Aufgabe zu erledigen hat. Zum Beispiel aus dem Bereich der Automation: Steuerung eines Regallager.
Unabhängig von der Implementierungssprache (Java, C++, C# um ein paar Beispiele zu nennen) machst du Dir also zunächst Gedanken aus welchen Komponenten dein Programm besteht. Zum Beispiel
- einer Datenbank um die Positionen der Waren im Lager zu merken
- eine Ablaufsteuerung um Waren einzulagern oder zu beziehen
- einer Komponente um eine Inventur der Waren zu ermöglichen
- einer Oberfläche um Daten zu importieren, exportieren oder schlichtweg diese manuell einzugeben
Die Software ist nun offensichtlich in mehrere Schichten/Komponenten eingeteilt, die für die Durchführung ihrer Aufgabe spezialisiert sind: Zugriff auf die Datenbank, Anzeige der Oberfläche oder Ein-/Ausgabe.
Dies ist wie gesagt nur ein Beispiel.
Dieses Schneiden der Software, also das Aufteilen deines Programms in diese Komponenten nennt man Schichtenarchitektur. Du findest hierzu auch andere Begriffe im Netz wie z.B. "Seperation of concerns". Die Motivation hierfür ist im wiki-Link beschrieben.
Bei der Softwaretechnik ist aber die Notation (die Syntax) der Programmiersprache oder des eingesetzten Framework natürlich nicht zu vernachlässigen.
Nehmen wir mal für den Zugriff auf die Datenbank wird ein Software-Framework (eine Datenbank Bibliothek) eingesetzt. Typischerweise erledigen solche Frameworks folgende Aufgaben: Datenbankverbindung aufbauen, Transaktionssicherheit, CRUD-Operationen für den Datenbankzugriff und weitere. Diese "Infrastruktur" dient nur dem technischen Zugriff auf die Datenbank, hat aber zunächst nichts mit dem Bauen deiner Steuerung für das Regallager zu tun!
Jetzt kommen wir langsam zur Geschäftslogik.
Worum geht's? Es geht darum das Wissen, die Durchführung (die Logik) deiner Problemstellung die du lösen möchtest als Software Engineer von der technischen Infrastuktur zu entkoppeln.
Diese "Fachlichkeit" und die "Technik" (der Sprache, Framework") sollen möglichst wenig miteinander zu tun haben. Dies macht Software wartbar, testbar und verständlich. In Verbindung mit der objektorientierten Programmierung sind hieraus eine Reihe von "Mustern" entstanden die Geschäftslogik von Technik trennen. Zum Beispiel Model-View-Control, Data Access Object (DAO) und weitere.
Ganz einfach: Stell dir jemanden vor, der sich nicht einen Meter mit Computern und Programmierung auskennt, aber mit dem Ablauf seiner Arbeit (zum Beispiel Buchungen im Rechnungswesen). Wenn du gerade Business-Logik implementierst, solltest du nur Begriffe in deinem Code sehen, die auch dieser nicht IT-affine Mensch benutzen würde.
Wenn man programmieren kann, dann versteht man die Wikipedia-Erklärung.
Einem Laien das zu erklären, wird schwierig werden, da die Erklärung weiteres Wissen voraussetzt.
Wenn Dich programmieren interessiert, fang´ einfach von ganz "unten" an und wenn Du dran bleibst, dann verstehst Du irgendwann "Geschäftslogik" automatisch durch die bereits erworbenen Kennntnisse.
Mit anderen Worten: Viel Code in modernen Anwendungen stellt einfach nur software-technische Infrastruktur da (hat also mit der geschäftslogischen Aufgabenstellung rein gar nichts zu tun).
Dies gilt ganz unabhängig davon, in welcher Programmiersprache die Anwendung implementiert ist.