Hey @Jojo0405

Databindings, Datasets und Dataadaptern aber kriege irgendwie die Verbindung zu dieser Vorgehensweise nicht hin

.
Ich hab dir da mal zwei Links mit denen das gut beschrieben ist. Ist zwar in Bezug auf eine Access DB hat aber vom Code her keinen Unterschied
1. Teil Allgemein, Laden etc
youtube.com/watch?v=XRVBpTFa3To
2.Teil, Befehle, Add, Delete, Save
youtube.com/watch?v=FJI2GXfGx0k

Teil 3/4 findest du dann in YouTube

Jojo0405 schrieb:

...Ich höre immer sehr viel von Databindings, Datasets und Dataadaptern aber kriege irgendwie die Verbindung zu dieser Vorgehensweise nicht hin.

Klar logisch kriegst du keine Verbindung von deiner Vorgehensweise zu Databindings, Datasets und Dataadaptern hin - der Grund ist, dass deine Vorgehensweise es vollkommen blockiert, von vornherein.
Um in den Genuss von Databindings, Datasets und Dataadaptern zu kommen musst du deine Vorgehensweise komplett vergessen und davon ablassen.
Ein Weg (nicht der beste, und fraglich, ob auf deim System, mit Firebird gangbar) zeigen die verlinkten Videos auf.

Du solltest dir aber die Frage stellen, ob du die Prinzipien von Datenmodellierung überhaupt schon beherrschst. Also welche Tabellen und Relationen sind anzulegen, um ein bestimmtes Problem zu modellieren?
Wenn du das jetzt nicht abnicken kannst, und hier den Screenshot des ER-Diagramms eines deiner Datenmodelle anhängen - dann bist du noch nicht bereit, eine Datenbank aufzubauen.

Insbesondere bei Unsicherheit der Begriffe "Datenmodell, Relation, ER-Diagramm" ist offensichtlich, dass theoretische Grundlagen fehlen, ohne die eine Datenverarbeitung überhaupt keine Chance hat, zu einem Ergebnis zu kommen.
Daher rate ich fast immer davon ab, mit einer Datenbank anzufangen. Denn die genannten erforderlichen Grundlagen, also Datenmodellierung, Databinding, Datasets erarbeiten sich ohne DB um ein Vielfaches einfacher.
Ich hab ein Haufen Tuts gemacht zum Thema, also bei Interesse...

jo, das sieht gut aus !
Ausgezeichnet sogar - ist mir noch nie begegnet, dass jmd auf Anhieb in seinen Datenmodellen eine komplett konsistente Benamung vorgewiesen hat.

Für mich nur optisch ungewohnt - Ich würde die Relation-Pfeile immer andersrum ziehen, also von der Parent-Entity zur Child-Entity. Aber sorum ist vlt. sogar sinniger - die Pfeile sagen eindeutig: "Diese Entity verweist auf jene".

Von meine "Lehrmittel-Sammlung" wirst du also einiges locker überblättern können: Datenverarbeitungs-Vorraussetzungen

Anderes aber nicht, und besonders Punkt 1 lege ich dir ans Herz: Visual Studio - Empfohlene Einstellungen
Weil

VB.NET-Quellcode

1. txtTitel.text = reader("TITEL")

zeigt, dass du Strict Off proggst, also dein System noch nicht so eingerichtet hast, dass du beim Programmieren Datentypen klar unterscheidest. Die Frage nach dem Datentyp ist aber beim Proggen die Gretchenfrage.
Anschliessend mag sehr nett sein die vier Views auf Video - da kriegst du einen Überblick, was die Framework-Infrastruktur in Winforms für dich leisten kann - aber bitte wirklich erst anschließend!

Dennoch aber auch die anderen Punkte von Datenverarbeitungs-Vorraussetzungen gegen-checken, wie Oberflächen-Layout, das Zusammenbinden mehrerer Projekte, oder auch einfach die effektive Benutzung des VisualStudios (Debuggen, Doku-Recherche).

---

OT:

Also ohne mich jetzt weit aus dem Fenster lehnen zu wollen,...

Och - mit echter und falscher Bescheidenheit habichs nicht so - merkt man vlt. gelegentlich.
Immer feste raus-lehnen - "man fällt immer in Gottes Hand" (Paul Gerhard)

@Jojo0405

Tolles Diagramm!
Mit was hast du das gemacht?

MircoTuor schrieb:

Tolles Diagramm!

ach komm - der Dataset-Designer leistet doch eben dasselbe, oder findste nicht?

ErfinderDesRades schrieb:

ach komm - der Dataset-Designer leistet doch eben dasselbe, oder findste nicht?

schon...aber das Diagrammfinde ich genau so übersichtlich

Jojo0405 schrieb:

@MircoTuor
Das Diagramm habe ich mit IB Expert direkt aus meiner DB generiert.
IB Expert ist ein Administrations-Frontend für Firebird.

Danke

ähm - leider runter. Weil das ist Wpf, da geht man nochmal anders vor, nämlich nachm MVVM-Pattern.
CodeBehind der Xaml-Designer ist für Anfänger erstmal tabu, sondern Bindings sind im Xaml zu setzen.

Und Dataset und Wpf ist nochmal eine Leidensgeschichte, in dem Bereich glänzt Wpf durch dermassen viele Kinderkrankheiten, dasses einer Totgeburt ziemlich nahe kommt.

Ich weiß auch nicht, zu was ich raten soll

• Wpf ist schon eine tolle Technologie, und mit Zukunft
  
• erfordert aber fortgeschrittene Kenntnisse von Anfang an: Einbindung von Bibliotheken, Vererbungslehre, Namespaces, statische Felder, Interfaces, Databinding, und natürlich den MVVM-Pattern
  
• erfordert, eine zusätzliche Sprache zu erlernen, das Xaml, die nochmal anders tickt (deklarative Sprache)
  
• ist voll von Kinderkrankheiten, sodass man Xaml-Databinding (also eiglich das wesentliche) selbst sehr wohlwollend betrachtet als nur teilweise typisiert auffassen kann.
  
• Insbesondere mit typisierten Datasets kann man im Xaml nur ausschließlich untypisiert umgehen - ich finde sowas grad für Anfänger sehr "giftig".
  

Alle mir bekannten Wpf-Progger sind durch die WinForms-Schule gegangen, und haben dann vieles hinter sich lassen müssen.
So ist das nun die Frage, ob man über den Umweg des einfacheren WinForms sich entwickelt, oder obs effizienter ist (und obs ühaupt möglich ist), von Anfang an richtiges Wpf sich zu erarbeiten.

Ich denke, ich rate dir zu Entity-Framework, das ist die Alternativ-Technologie zu typDataset, ist auch moderner (und schwieriger). Leider geht EF überhaupt nicht ohne Datenbank, aber mit Dbs kommst du ja sehr gut zurecht. Auch das Konzept "Datenmodell" ist dir geläufig, daher wird MVVM mit seinem "ViewModel" dir sicherlich leichter begreiflich sein als anderen.

Nur wie vorgehen weiß ich nicht. Vlt. erstmal überhaupt eine Text-Datei in ein Viewmodel einlesen und mit Wpf sauber nach MVVM präsentieren, und zwar das komplette CRUD (laden/bearbeiten/rückspeichern).

Vorher würde ich nicht empfehlen, sich gleich mit EF rumzuärgern.
Also hier mal ein EF-Winz-Sample, aber richtig sauber ist das auch nicht, denn es heißt, man soll ObjectContexte nicht dauerhaft im Programm halten: EntityFramework-CodeFirst-Sample

Nein, Databindings werden niemals neu erstellt.
Mit Databinding zu arbeiten ist deklarative Programmierung: Man richtet die View (also was man am Ende wirklich sieht) einmal ein, und dann zeigt die View die Daten.
Daten ändern sich, die View bleibt.

Aber ich weiß jetzt nicht, ob du von Wpf oder von WinForms redest - wie gesagt: sind 2 komplett andere Welten.

jo, da wirst du wohl alles vergessen müssen, was du in wpf je gemacht hast, und wie in post#11 vorgeschlagen neu und klein anfangen, und v.a. erstmal ohne Datenbank.

Die erste Hürde ist genommen, wenn du das vorgeschlagene Übungsprojekt korrekt nach MVVM aufgesetzt hast.
MVVM-Korrektheit erkennt man am Ende ganz schnell: nämlich wenn der CodeBehind der Windows leer ist - sich also alle Logik im Viewmodel abspielt.

Guck halt dazu den Wpf-Tutorial-Bereich durch, da gibts recht viel zu MVVM, und zu Wpf lernen überhaupt, und auch viele Tuts mit Sample-Downloads.

Ja, da magst du recht haben.

Grad ein Tut zu eigentlich gar keinem Thema gibts glaub noch garnet.

Also ich hänge mal eine Solution an.

Bitte guck nur ins PersonList-Projekt - die anderen beiden (Helpers-) Projekte sind Infrastruktur, die das eigentliche nur unterstützen, und die nachzuvollziehen jeden Rahmen sprengen würde.

naja, ein ganzes System von DataAdaptern musst du in Anschlag bringen.
Für jede Tabelle im typisierten Dataset eine.

Aber für dich käme eiglich eher EntityFramework in Frage, denn beim EF unterstützt der Xaml-Designer das Setzen von Bindings mittels Assistenten.
Bei typisiertem Dataset (befüllt aus DataAdaptern) erleidet man da ziemliche Einschränkungen, und ich denke, ist nicht gut, Wpf nur eingeschränkt funktionsfähig kennenzulernen - da wird man die Wpf-Power nicht wirklich für sich entdecken.
S. Link in post#11.

Jedenfalls die allgemeine Struktur sollte klar sein: Für verschiedene Datensätze (und ggfs. weitere Datentypen) jeweils eine Viewmodel-Klasse, und alle Viewmodels fließen im MainViewmodel zusammen, wovon inne App.Xaml eine Instanz in den Resource plaziert ist.
An diese Instanz kann alles Xaml binden, sowohl mit Daten-Preview zur DesignZeit, aber dann auch mit Wirkung zur Laufzeit.

Ich bin auch dran, ein Tut zu basteln, was nochmal besonders auf diese prinzipielle Architektur abhebt.