verwendetes Datenbanksystem: MYSQL

Hallo ich habe eine allgemeine Frage. Wenn ihr daten abfragt von einer datenbak, spielt ihr die daten direkt in die formularfelder oder eröffnet ihr zuerst eine classe.
zum beispiel ich habe eine adressdatenbank mit namen vorname. wenn ich jetzt eine anwendung schreibe wird dann zuert eine classe person erstellt mit name und vorname und von dort die daten in das formular übergeben.

vielen dank für eine antwort
joshua

Hallo joshua,

ich arbeite immer mit dem Entity Framework. Und ja dort wird eine Datenklasse entsprechend aller Spalten und Beziehungen der Datenbankschicht erstellt.
Denn durch diese Wrapper-Klassen vereinfacht man sich die Arbeit mit der Datenbank sehr.

Stichpunkt: O/R-Mapper

Gruß
Michael

Vielen Dank für den Tip
werde ich gerne versuchen
gruss joshua

Hallo joshua,

wegen der Vollständigkeit sei erwähnt, dass es beide Varianten gibt.
Details findet man utner folgenden Links:
typed oder untyped Dataset
3-Schichten-Design?? [harte vs. weiche (Daten-)Objekte / OOP vs. ActiveRecods]

Gruß
Juy Juka

Hallo Juy Juka

Vielen Dank für den Hinweis, ich werde die beiden links gerne anschauen.

Gruss Joshua

Bei mir läuft aktuell auch der Kopf heiss... Daher hänge ich mich hier an das Thema einfach mal ran.

Ich habe viele Jahre non-OOP in PHP programmiert...
Seit einigen Wochen versuche ich mich an c#

Extrem geholfen zum Grundverständnis des "Handwerkzeugs" haben mir folgende videos: http://www.j3l7h.de/videos.html#a3
Zum Thema Application Design wollte ich mich gerne am 3-Schichten Modell orientieren mit einer Vertikalschicht für Klassendefinitionen und Klassenübergreifende Interfaces.
HowTo: 3-Tier / 3-Schichten Architektur

Aktuell gehe ich so vor:
Ich habe Klassen für die entsprechenden Datensätze und baue mir aus den Klassen mit Hilfe von Datenbankanfragen (auf eine accdb-Datei) meine Objekte.
Also ich möchte quasi zur Laufzeit tatsächlich nur mit Klassen-Instanzen arbeiten.
Allerdings scheint das ein enormer Aufwand zu sein. Gerade auch mit dem 3-Schicht System.
Die Objekte schmeiße ich dann in ein Dictionary<int, KLASSE> wobei das int gleichzeitig die KLASSE.id ist.

Ist das soweit korrekt oder habe ich hier schon den 1. Denkfehler?
Ich lese immer nur was von Listen usw... aber wie kommt man dann denn an die einzelnen Objekte ran, ohne immerzu die ganze Liste durchzugehen mit Schleifen und nach der Objekt ID zu suchen?!?


Ich komme jedenfalls gerade ins Zweifeln, ob ich einen falschen Denkansatz habe bzw. ob es "Fertiglösungen" dafür gibt (wie die hier oft beschriebenen O/R-Mapper) oder ob es einfach mal Tatsache ist, dass es so heiden viel Arbeit ist.

Ich habe auch noch keinen Ansatzpunkt, wie ich das mit dem Zurückschreiben in die DB realisieren soll.

Vielleicht was es etwas zu hoch gegriffen, als 1. Projekt gleich auf 3 Schichten zu setzen *seufz*.


Ach ja, ich bin gelernter Anwendungsentwickler aber leider bisher ohne echte Praxis in OOP bzw. Windows-Programmierung allgemein.

Hallo BloodyLove,

genau für deine Denkansätze wurden u.a. O/R Mapper gemacht.
Einfach gesagt, arbeitet man dabei mit den direkten Daten der Datenbank, d.h. die Object-Schicht stellt 1:1 die Datenbank da.

Zitat von BloodyLove

Ich habe auch noch keinen Ansatzpunkt, wie ich das mit dem Zurückschreiben in die DB realisieren soll.

Bei O/R: Daten im Object ändern und SaveChanges aufrufen, und fertig.

Zitat von BloodyLove

ohne immerzu die ganze Liste durchzugehen mit Schleifen und nach der Objekt ID zu suchen?!?

Bei O/R "gehst" du die Listen mit LINQ-Abfragen durch. Vereinfacht sind LINQ-Abfragen auf Listen ähnlich wie SQL-Abfragen auf der Datenbanktabellen mit JOINS und allem drum und dran.

z.b. Wird dann auf Datenbankebene:
SELECT TOP(1) * FROM MeineTabelle WHERE Id = 5

Weitere Stichpunkte: Code First, Database first

Gruß

Hallo BloodyLove,

Das IDictionary<int,?> ist nich immer falsch aber das kommt ganz auf die Sichtbarkeit/den Gültigkeitsbereich an.
Normalerweise sollte ich mir immer nur die Objekte laden, welche ich auch wirklich brauche (wird auch Lazy Loading genann), daher muss ich nicht in den geladenen Listen im Arbeitsspeicher suchen.
d.h. wenn dein IDictionar<int,?> static ist, ist sein Gültigkeitsbereich viel zu groß. Wenn dein IDictionar<int,?> eine Instanz-Variable ist oder sogar nur lokal in enier Methode geladen wird, muss man das immer noch überlege, aber die Warscheinlichkeit dass es richtig ist ist höher.

((Pseudo Beispiel Code
Ich empfehle dir einen fertigen O/R Mapper zu verwenden, da hier viele Fehler eben gleich vermieden werden. Aber aus OO-Sicht ist es eigentlich egal wie du an deine Objekte kommst, darfst diese natürlich selber zusammen bauen, wenn du einen Grund dafür hast.

Und mach dir keine Sorgen wegen 3-Schichten beim ersten Projekt, ja das Projekt wird länger dauern ABER du wirst es schaffen und danach wissen wie man es macht und das ist es wert.

Gruß
Juy Juka

Wie du schon richtig geahnt hast:
Ich habe im DataAccess-Layer ein Interface und die entsprechende .cs datei zum holen der Daten aus der accdb-Datei nach dem Schema der Klasse aus dem vertikalen Model-Layer.
Und zwar für jede Tabelle einzeln. Also eine Interfacedatei und eine Worker-Datei je Tabelle.

Der Business-Layer sorgt für die Sortierung und Eintragung von Sondersachen...
Z.B. bei "Kategorien" habe ich den Sonderfall, dass sie multidimensional / rekursiv sind, wie auch immer man das sagen will...
Kategorie hat also ein Feld ParentID, was besagt, dass eine unendliche tiefe oder breite Baumstruktur vorhanden sein kann... durch nur diese eine Tabelle

Zuerst hatte ich die oberste Ebene belassen (ParentID = 0) und der Klasse Kategorie eine Property in Form wieder eines Dictionary<int ID, Kategorie KategoObject> gegeben, sodass die Kindobjekte sich tatsächlich in den Mutterobjekten befunden haben und eine ECHTE struktur entstanden ist - nicht mehr nur eine Verweis-Struktur.
Mittlerweile habe ich das geändert in eine Methode getChilds mit dem Rückgabetyp des Dictionary<int ID, Kategorie KategoObject>.
D.h. die Kindobjekte werden nun nur geladen, wenn sie wirklich benötigt werden.

Im Presentation-Layer / View hole ich mir anhand von Interfaceobjekten die Dictionarys z.B. über getKategorien() -> normale Liste bzw. getKategorienDimensional -> Liste mit ECHTER Struktur / also kindobjekte nicht auf gleicher Ebene wie Elternobjekte. Die implementierung der get-Funktionen ist im Business-Layer - abgerufen wirds aber per interface vom View!

Dort arbeite ich quasi mit den Dictionarys der datensätze, welche ja die Rückgaben der Getter vom BL sind.

Wobei ich das Listen-Stricken usw. auch nochmal ausgelagert habe in extra CS-Files - d.h. das mache ich nicht direkt im frmMain.cs-code!
Um einfach in anderen Fenstern auch einfach darauf zugreifen zu können usw.

Ich hoffe man kann das einigermaßen verstehen...

Allerdings habe ich soeben beschlossen, mir erstmal ein paar O/R-Mapper anzusehen und dann einen Solchen zu verwenden.
Ich hoffe, ich muss mich dafür nicht schämen.

Hallo BloodyLove,

Alles habe ich nicht verstanden, aber erst mal einen OR-Mapper zu verwenden ist sinnvolle und ist überhaupt kein grund zum schämen.

Gruß
Juy Juka