Einfache Kundenverwaltung, guter Programmierstil

[FreiWild]

Hallo zusammen,

Ich will mich ein wenig mit der Java, bzw. der Android Programmierung befassen. Ich habe vor, einfach eine simple Kundenverwaltung zu schreiben. Doch da fängt das Problem schon an :-)

Ich möchte natürlich nichts runter programmieren, was ich danach gleich wegwerfe. So eine Kundenverwaltung kann man später ja immer mal gebrauchen. Vielleicht wächst die Anwendung ja auch kontinuierlich weiter...

ich bin mir aber nicht so ganz sicher, wie ich das ganze am saubersten angehe. Dass es sich hier um eine Andoid Anwendung handelt, halte ich erstmal für nebensächlich. Ich will euch aber erstmal zeigen, wie ich mir das gedacht habe.

Ich habe erstmal mit einer Einteilung in drei Schichten begonnen: Präsentationsschicht, Logikschicht und Datenhaltungsschicht.

Interessant ist für mich erstmal die Logikschicht. Hier will ich Kunden anlegen, suchen, bearbeiten und löschen können. ich habe eine Klasse Person und eine Klasse Metaperson, die die Personen anlegt und verwaltet. ich kenne mich da nicht so gut aus, aber ich habe da an die Fabrikmethode gedacht. Ich fürchte nur, dass mein Gedanke nicht ganz mit dem der Fabrikmethode übereinstimmt. Habe bisher nur darüber gelesen.

wie sollte so etwas am besten aussehen? mir geht es darum, das ganze besser zu verstehen und einen sauberen, wiederverwendbaren code zu schreiben. Wenn mir jemand helfen kann, sei es mit einer Zeichnung oder einem abstrakten Codebeispiel. ich wäre euch echt dankbar.

So habe ich mir das gedacht:

Anlegen und Suchen in der Datenhaltungsschicht über "Metaperson" , bearbeiten direkt über die Klasse Person.

Metaperson macht select und insert in Datenhaltungsschicht, Person macht update und delete.

Brauche ich zwingend Oberklassen, etc. (Fabrikmethode). Was ist sinnvoll?

Vielen Dank...

[lbm1305]

Zum Thema Clean-Code:

Du solltest zuerst zwei Prinzipien kennen:

Single Responsibility Principle

Open-Close Principle

SRP bedeutet, dass jede Klasse nur einen Grunde haben sollte, verändert zu werden.

Bspw. eine Klasse, die eine Connection herstellt, eine Abfrage gegen eine Persistenzschicht fährt und dann noch die Daten aufarbeitet entspricht nicht dem SRP. Daher solltest Du darauf achten, dass Klassen nur eine Aufgabe haben. Dementsprechend sollte auch jede Methode / Funktion einer solchen Klasse nur eine Aufgabe wahrnehmen.

Das Open-Close Prinzip sagt nichts anderes, dass eine Klasse für Veränderungen geschlossen ist, für Erweiterungen aber offen.

Beispiele findet man zu Hauf im Netz. Einfach mal nach SOLID (jeder Buchstabe ein Prinzip) suchen. Ansonsten kann ich die Seite clean-code-developer empfehlen.

[FreiWild]

Danke dir,

Werde mal nach den Begriffen schauen.

Habe mal schnell was aufgemalt. Ist das so sinnvoll? Wenn du es lesen kannst

[lbm1305]

Eine Aufteilung auf 3 Layer ist schon sinnvoll. Hier hast Du eine Übersicht zu einer DemoApp für .NET

Layered Architecture Sample for .NET

Der DataLayer führt die eigentlichen Abfragen aus und liefert die Daten als Aufzählung zurück. D.h. auch, dass der DataLayer zum Speichern ein Objekt übergeben bekommt, welches persistiert werden soll. Die Businesslogik (BusinessLayer) verarbeitet dann diese Objekte und kommuniziert mit der UI (PresentationLayer). Die Services sind nicht unbedingt von nöten.

[HJST1979]

Hallo

ich beschäftige mich derzeit privat auch mit der 3-Schichten-Architektur. Habe mein Programm auch schon entsprechend aufgeteilt.

DataAccessLayer

-> DB- Connection

-> SQL- Befehl- Verarbeitung

-> Zurückliefern eines "Objekts"

-> Speichern der mit dem übergebene Objekt verbunden Daten in die DB

BusinessLayer

-> Derzeit werden hier "nur" die Objekte durchgereicht

PresentationLayer

-> Anzeigen der Daten aus dem Objekt in der Maske und verändern des Objekts falls der Endanwender in der Maske etwas eintippt.

Was ich nicht so richtig verstanden habe ist, was gehört tatsächlich in die BusinessLayer ? Vielleicht kann mir hier jemand helfen.

@FreiWild Ich baue auch eine Kundendatenverwaltung auf :-)

Gruß Hans-Jörg

[flashpixx]

Was ich nicht so richtig verstanden habe ist, was gehört tatsächlich in die BusinessLayer ? Vielleicht kann mir hier jemand helfen.

Ich würde darunter die "semantische Logik" zählen

[HJST1979]

Ich würde darunter die "semantische Logik" zählen

Ich versuche mal ein Beispiel

- Ich habe in meiner "Maske" 2 numerische Eingabefelder

- Die Summe aus den Eingaben muss ermittelt werden

=> heißt dass dann, dass dieses "Summenermitteln" in die Businesschicht kommt ???

Gruß Hans-Jörg

[flashpixx]

=> heißt dass dann, dass dieses "Summenermitteln" in die Businesschicht kommt ???

Ist vielleicht kein gutes Beispiel, aber ich würde sagen "ja". Ich würde eher bei einer Kundenverwaltung sagen, dass ein Kunde ohne Adresse nicht existieren kann. Die GUI Elemente geben die Daten weiter und dort wird geprüft, ob eben alle Daten vollständig und integer sind, bevor sie dann weiter an den Data-Access-Layer gereicht werden und mit der Datenbank kommunizieren.

Je nach gewählter Sprache würde ich sogar von einem Datenbank-Layer absehen und Techniken wie Hibernate einsetzen. Damit würde die Business-Logik entsprechend direkt mit den Objekten arbeiten, die Kommunikation zur Datenbank und die Integrität muss man dann nicht selbst schreiben

[HJST1979]

Hallo

Heißt wenn ich bei einer Kundenverwaltung das Namensfeld als Pflichfeld definiere, der Endanwender aber nichts einträgt würde die Businesschicht dies Abfangen !

Gruß Hans-Jörg

[lbm1305]

Die Validierung bei WindowsForms-Anwendungen müsste in der UI-Schicht passieren. z.B. bei LostFocus() einer Textbox. Es wäre aber auch möglich, die Validierung im Business-Objekt (BusinessLayer) durchzuführen und den Fehler wieder an die UI zurück zu melden. Lösungen zum Anzeigen von Fehlern sind der ErrorProvider oder eine MessageBox, wenn der Benutzer z.B. auf Speichern klickt. Es gibt da aber kein Patentrezept.

Business-Layer und Datenbank-Layer dürfen keine MessageBoxen etc. auslösen.

Dies ist der UI-Schicht vorbehalten.

[lbm1305]

Je nach gewählter Sprache würde ich sogar von einem Datenbank-Layer absehen und Techniken wie Hibernate einsetzen. Damit würde die Business-Logik entsprechend direkt mit den Objekten arbeiten, die Kommunikation zur Datenbank und die Integrität muss man dann nicht selbst schreiben

Hmm...bin da anderer Meinung. Nehmen wir an, die Anwendung ist für alle möglichen DBMS ausgelegt, dann bringt mir (N)Hibernate recht wenig. Da würde ich es vorziehen, die reine BusinessObjekt zu schreiben und diese dann im DataLayer nochmals zu mappen.

Hatte dazu auch mal einen Webcast von Dariusz Parys gesehen, wo er dies selbst praktiziert bzw. erwähnt.

[flashpixx]

Nehmen wir an, die Anwendung ist für alle möglichen DBMS ausgelegt, dann bringt mir (N)Hibernate recht wenig.

Naja wenn Du mehrere DBMS ansprechen willst, würde ich es auch anders machen. Unter Java würde ich wohl Hibernate nehmen, hat man aber eine cross-plattform Anwendung ist das ganze schon schwieriger, aber dennoch möglich. Ich denke letztendlich muss man das Objekt entsprechend serialisieren und die Objekt Daten in die Datenbank schreiben.

Unter C++ würde ich wohl die Boost nehmen und in den Klassen das Serialization implementieren, wobei ich dann nur einen eigenen Stream benötige, der die Datenbankverbindung hält und die Daten liest bzw schreibt.

Wenn man diesen Layer einmal hat, kann man natürlich dann z.B. auch eine PHP oder Java oder C++ Anwendung haben, die eben zentral in der Datenbank die Objekte hält und dann in passende Objekte lokal umwandelt