Tweet
Hi,
ich bin gerade dabei eine erste Test-Applikation mit Visual Basic .NET in Visual Studio Express 2010 zu erstellen. Als Datenbank kommt dabei Jet (Access 2003) zum Einsatz.
Bisher habe ich weder ein ansprechendes Buch noch gute Web Sites - außer dieser hier
- für professionelle Anwendungsentwicklung gefunden ... Vorschläge? 
Von dem was ich bezgüglich der Anbindung einer Datenbank bisher gelesen und meine verstanden zu haben, repräsentiert das DataSet meine Datenstrukturen, dh ich kann hier meine Abfragen, Queries usw zur Verfügung stellen, damit nachgelagerte Objekte leichter auf die Datenstrukturen zugreifen können.
Wenn ich es mit mehreren Datenbanken und weiteren Arten von Datenquellen zu tun habe: Sollte ich dann alle in einem DataSet hinterlegen oder sollte ich jeweils ein DataSet für Datenbanken, eins für Web Services usw anlegen oder lieber für jede Datenquelle?
Ein TableAdapter lädt die Daten aus der Datenquelle und stellt sie dem DataSet zur Verfügung. Gleichzeitig sorgt er auch umgekehrt für die Speicherung von Änderungen. Der TableAdapter kann dabei sowohl einfache Tabellen als auch über SQL Daten einer Abfrage zurückliefern.
In einer normalisierten Datenbank gibt es ja eher selten den Fall, daß Daten einer Tabelle direkt geladen und geändert werden sollen. Der Normalfall sind aus Gründen der Lesbarkeit und auch zur Restriktion ungewollter Zugriffe ja eher Abfragen, die aus den entsprechenden Tabellen die lesbaren Werte joinen und als Abfrageergebnis liefern.
Hier hat sich mir die Hauptfrage aufgedrängt: Nehmen wir an, ich hätte zwei Tabellen, deren Join genau die Daten enthält, die ich in einem DataGridView anzeigen und bearbeiten lassen möchte; dann gibt es offenbar mehrere Optionen:
Lange Rede, kurzer Sinn: Wo und wie soll ich meine Abfragen realisieren?
Ein TableAdapter bietet die Option neben Fill() und GetData() auch noch weitere eigene Methoden zu definieren, die andere SQL-Statements (auch mit Parameter) enthalten können.
Wenn ich in einem DataGridView eine Untermenge von Daten anzeigen lasse, könnte ich dies sowohl über eine TableAdapter-Funktion als auch einen Filter realisieren. Wann nehme ich was?
Die DataBindingSource ist der "Vermittler" zwischen dem Control und dem TableAdapter und befriedigt die Datenbedürfnisse des Controls entsprechend.
Ich mag die Optik des DataGridViews nicht besonders. Gibt es auch die Möglichkeit zB einen ListView zu einem DataListView zu "extenden"?
Das wären erstmal meine grundlegenden Fragen - ich freue mich schon sehr auf die erleuchtenden Antworten und die Erfahrungswerte aus der Praxis ...
ich bin gerade dabei eine erste Test-Applikation mit Visual Basic .NET in Visual Studio Express 2010 zu erstellen. Als Datenbank kommt dabei Jet (Access 2003) zum Einsatz.
Bisher habe ich weder ein ansprechendes Buch noch gute Web Sites - außer dieser hier
- für professionelle Anwendungsentwicklung gefunden ... Vorschläge? Von dem was ich bezgüglich der Anbindung einer Datenbank bisher gelesen und meine verstanden zu haben, repräsentiert das DataSet meine Datenstrukturen, dh ich kann hier meine Abfragen, Queries usw zur Verfügung stellen, damit nachgelagerte Objekte leichter auf die Datenstrukturen zugreifen können.
Wenn ich es mit mehreren Datenbanken und weiteren Arten von Datenquellen zu tun habe: Sollte ich dann alle in einem DataSet hinterlegen oder sollte ich jeweils ein DataSet für Datenbanken, eins für Web Services usw anlegen oder lieber für jede Datenquelle?
Ein TableAdapter lädt die Daten aus der Datenquelle und stellt sie dem DataSet zur Verfügung. Gleichzeitig sorgt er auch umgekehrt für die Speicherung von Änderungen. Der TableAdapter kann dabei sowohl einfache Tabellen als auch über SQL Daten einer Abfrage zurückliefern.
In einer normalisierten Datenbank gibt es ja eher selten den Fall, daß Daten einer Tabelle direkt geladen und geändert werden sollen. Der Normalfall sind aus Gründen der Lesbarkeit und auch zur Restriktion ungewollter Zugriffe ja eher Abfragen, die aus den entsprechenden Tabellen die lesbaren Werte joinen und als Abfrageergebnis liefern.
Hier hat sich mir die Hauptfrage aufgedrängt: Nehmen wir an, ich hätte zwei Tabellen, deren Join genau die Daten enthält, die ich in einem DataGridView anzeigen und bearbeiten lassen möchte; dann gibt es offenbar mehrere Optionen:
- TableAdapter für eine Query aus der Datenbank - sind die generierten INSERT / UPDATE / DELETE Statements wirklich in der Lage beide Basistabellen entsprechend zu pflegen?
- TableAdapter mit SELECT-Statement - gleiche Frage wie zuvor; der einzige Unterschied wäre hier, daß neue Abfragen direkt im DataSet erstellt werden könnten, wobei ich mir noch nicht sicher bin, ob das ein Vor- oder Nachteil wäre.
- Zwei TableAdapter und ein Abfrage-Objekt - das imitierte die Datenbank im DataSet; auch hier stellt sich die Frage, ob es vorteilhafter ist als eine Abfrage in der Datenbank zu erstellen.
- ADO.NET/DataAdapter mit SQL-Statements direkt im Code - damit beraubte ich mich sicherlich einiger Automatisierungs- und Pflegevorteile im Gegensatz zur Realisierung mit den dafür vorgesehenen Objekten
Lange Rede, kurzer Sinn: Wo und wie soll ich meine Abfragen realisieren?
Ein TableAdapter bietet die Option neben Fill() und GetData() auch noch weitere eigene Methoden zu definieren, die andere SQL-Statements (auch mit Parameter) enthalten können.
Wenn ich in einem DataGridView eine Untermenge von Daten anzeigen lasse, könnte ich dies sowohl über eine TableAdapter-Funktion als auch einen Filter realisieren. Wann nehme ich was?
Die DataBindingSource ist der "Vermittler" zwischen dem Control und dem TableAdapter und befriedigt die Datenbedürfnisse des Controls entsprechend.
Ich mag die Optik des DataGridViews nicht besonders. Gibt es auch die Möglichkeit zB einen ListView zu einem DataListView zu "extenden"?
Das wären erstmal meine grundlegenden Fragen - ich freue mich schon sehr auf die erleuchtenden Antworten und die Erfahrungswerte aus der Praxis ...
Comment