Programmierstil

D

devencer

Grünschnabel
Hi

Ich programiere seit August mit VB.NET. Es ist die erste objektorientierte Sprache, mit der ich mich intensiv beschäftige. Nach vielen Lesen und Probieren habe ich nun zwei Programme mit Access-Backend entwickelt, die beide ihren Zweck tadellos erfüllen.

Als ich das erste mal über Objektorientierung gelesen hatte, dachte ich mir, das ist ja praktisch, aber bei der Implementierung war ich mir dann doch etwas unsicher, wo welche Codeabschnitte hingehören. Wenn ich mir den Code meiner beiden Programme ansehe, habe ich u.a. manchmal die Validierungen in der Form-Klasse, manchmal in der DB-Klasse geschrieben, wo ich meine SQL-Methoden reingepackt hatte.

Mich würde nun interessieren, bloss ganz allgemein, an welcher Stelle welcher Code implementiert werden sollte, um einem guten Programmierstil gerecht zu werden. Oder ist es letztendlich bloss eine Frage der Übersichtlichkeit, wenn man von kleineren Applikationen ausgeht? Und hat vielleicht wer einen Tipp für passende Lektüre zum Thema Objektorientierung und Programmierstil?

Vielen Dank schon mal :)

Gruss & frohe Weihnachten
devencer
 
Bei uns auf der Arbeit ist es eigentlich geregelt das es DLLs für die Objekte (Stammdaten, Objekte die überall wieder auftauchen) gibt und DLLs für die GUI (grafische Anzeige)
Über so genannte Manager Klassen (deine DB Klasse) werden die Daten aus der DB abgefragt.

Sprich:
DLL Adressen.dll
hält eine Klasse Adresse mit Vorname, Nachname, Strasse, etc
hält eine Klasse AdressenManager mit der Methode LadeAdresse, als Rückgabetyp Adresse

DLL AdressenUI.dll
kümmert sich um die grafische anzeige, greift dabei auf das Objekt Adresse aus Adressen.dll zurück und ruft die Methode LadeAdresse auf.

Wie man sieht gibt es bei uns nur 2 Schichten.
Eigentlich gibt es dafür ein (glaube) 3 Schichten Modell dessen Name mir nicht einfält. In der DB, Objekte und GUI noch strenger getrennt sind.

Hoffe ist verständlich.
 
Stimmt, eigentlich gibt es dafür 3-Schichten-Modelle. In der einfachsten und häufigsten Ausprägung wäre das das MVC-Pattern.

MVC steht für "Model View Controller". Dabei sind im Model die Daten definiert, die View dient der Anzeige der Daten und der Controller steuert die ganzen Prozesse. Dabei sollte natürlich alles so aufgebaut sein, das einzelne Schichten einfach durch andere ausgetauscht werden können und die anderen 2 Schichten dafür nicht angepasst werden müssen (Stichwort: Interfaces).

Ein gutes Buch zur Objektorientierten Programmierung findest du hier: http://openbook.galileocomputing.de/oo/
 
Vielen Dank für eure Antworten!

Ich bin mir nicht sicher, ob ich das nun richtig verstanden habe. Dass die Daten von der Ansicht getrennt werden sollten leuchtet mir ein. Doch wie weit geht das? Wenn das Programm eine Anfrage an einen SQL-Server sendet, würde vom Form ein Ereignis ausgelöst, dieses erstellt ein Objekt der entsprechenden Klasse, in der Klasse wird die SQL-Anfrage durchgeführt, und was nun? Werden in der Praxis nun die Daten von einer Function zurückgegeben und im Form z.B. in ein ListView eingetragen oder sollte dieser Vorgang direkt in der Klasse durchgeführt werden? Oder sollte wiederum eine andere Klasse instanziiert werden, die dann für diesen Schritt verantwortlich ist?

Danke für den Buchtipp. Ich werde mir dieses Buch bei Gelegenheit ansehen!

Gruss
devencer
 
Wie gesagt bei uns gibt es Basisklassen die jedes Programm verwendet.
Nun ist es so wenn Daten für die GUI angezeigt werden sollen läuft es meistens über Datenbindung. Dann wird etweder die entsprechende Basisklasse vererbrt (lös bar mit Hilfe von Generic, "<T>"). Oder es wird ein entsprechendes Hilfsobjekt erstellt oder wenns passt nimmt man halt direkt das Stammdatenobjekt.

Bei uns ist es so das wir ein eigenes Objekt für Datenbankverbindungen etc halten das von DbConnection abgeleitet ist, so kann der User die DB selbst wählen. Worauf wir nur achten müssen ist das alle entsprechend unterstützten DBs die SQL Anweisungen interpretieren können.
 
Hi

@Spyke

Ein 3-Schichten schreibt nicht vor, dass die einzelnen Schichten in einzelne DLLs gepackt werden müssen, Diese 3 Schichten können in einer Datei, in drei aber auch in 30 sein. Der Umfang des Programmes ist entscheidend wie man es aufgliedert.

Hier wäre jedoch das 3-Tier Modell möglich. Dabei gibt es wirklich 3 von einander unabhänige Schichten. Jede Schicht kommuniziert nur mit ihrem direkten Nachbarn.
(Front-End kümmert sich um die Darstellung, Middleware um die Business-Rules und das Back-End um die Persitenz). Im Front-End kann jedoch z.B. auch wiederrum das MVC-Pattern zum Einsatz kommen.
 
Nico Graichen hat gesagt.:
Hi

@Spyke

Ein 3-Schichten schreibt nicht vor, dass die einzelnen Schichten in einzelne DLLs gepackt werden müssen, Diese 3 Schichten können in einer Datei, in drei aber auch in 30 sein. Der Umfang des Programmes ist entscheidend wie man es aufgliedert
Zum Vergrößern anklicken....

Nene so meinte ich das ja auch garnicht mit dennen einzelnen DLLs, aber deine weiteren Ausführungen zeigen wie ichs meinte ;)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück