Laden...

[erledigt] MS-SQL-Select in ObservableCollection speichern

Erstellt von m.grauber vor 13 Jahren Letzter Beitrag vor 13 Jahren 3.765 Views
M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 13 Jahren
[erledigt] MS-SQL-Select in ObservableCollection speichern

verwendetes Datenbanksystem: <MS-SQL-Server 2000 - 2008>

Hallo,

ich bin ein Anfänger und habe bereits viel gesucht aber noch keine übergreifende Antwort auf meine Fragen gefunden:

Daten vom SQL-Server, SQL-Server-Compact und später vielleicht einmal MySQL oder eine andere Datenbank soll im WPF-Programm in eine Observable Collection gespeichert werden. (Lesen und zurückspeichern und an WPF binden)

  1. Ist die Observable Collection zum aktuellen Zeitpunkt VS2008/2010 tatsächlich die empfehlenswerteste Collection (Performance, Möglichkeiten) und sollte man besser nicht mehr mit DataTables arbeiten? Gibt es evtl. eine bessere Collection? Ich möchte später so wenig wie möglich unterschiedliche Collections nutzen und es sollte eine sehr schnelle und einfache Möglichkeit sein.

  2. Beim Füllen einer ObservableCollection stelle ich mich noch schlecht an: Ich hole mir die Daten zuerst mit einem SQLDataReader (und ExecuteReader und dann mit Read()) und füge dann die einzelnen Daten mit einer Schleife ein. Das ist bei großen Datenmengen sicher zu langsam. Gibt es hier eine Möglichkeit, die Werte direkt und auf einen Schlag in eine ObservableCollection einzufügen?

  3. Ist es sinnvoll von allen auf dem SQL-Server existierenden SQL-Tabellen einzelne Klassen mit allen Feldern zu erstellen, die es auf dem SQL-Server gibt um diese Klasse dann für die ObservableCollection zu nehmen? Kann man sich diese Klassen nicht komfortabel und dynamisch beim Lesen vom SQL-Server selber erstellen lassen?

Vielen Dank!

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]

F
10.010 Beiträge seit 2004
vor 13 Jahren

Tja, gute Fragen die zeigen, das Du erst nach Lösungswegen als nach Grundlagen gesucht hast.

Was Du machen willst, ist einen ORMapper benutzen oder Nachbauen.

Und ob das besser oder schlechter als DataTables ist kommt ganz auf deine Anwendung an.
Zu dem Thema haben wir hier einiges an Beiträgen, die teilweise in (fast)Glaubenskriege münden.

M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 13 Jahren

Hallo,

Danke vielmals für Deine Antwort! Inzwischen habe ich mich intensiv zu anderen ORMappern eingelesen und bin weiterhin in meinem Fall der Auffassung, den ORMapper selbst zu schreiben. Es gibt sicher viele unterschiedliche Meinungen dazu.

Nur ist es in diesem Fall angebracht, im Programm nicht mit RecordSets zu arbeiten und stattdessen besser eine ObservableCollection zu nutzen - oder gibt es eine "bessere" (einfacher/schnellere) Collection dafür?

Entscheide ich mich für Collections muss ich also scheinbar tatsächlich den Umweg über den Recordset gehen und von dort aus alle Daten in die Collection kopieren. (Das kostet auch Zeit).

Ich habe gehofft, es gibt einen direkte Methode, die Daten - ohne über den Recordset - direkt in die Collection zu kopieren.

Die Daten sollen in WPF dargestellt/editiert werden.

Vielen Dank!

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]

F
10.010 Beiträge seit 2004
vor 13 Jahren

RecordSet gibt es in VB6, du meinst evtl DataTable/DataSet.

Dir fehlt trotz der Recherche noch so ziemlich alles an Grundlagen zu ADO.NET und du willst dir trotzdem eine ORMapper selber schreiben?

Der DataReader ist die schnellst Möglichkeit, nur warum willst Du dir das antun?
Wieso meinst Du das du mit einem eigenen ORMapper besser fährst also mit LinQ2Sql, EF, NHibernate .......?

Alles was Du selber scheibst ( gerade weil dir die Grundlagen fehlen ) wird bestimmt nicht besser funktionieren als diese tausendfach erprobt und getesteten Biblioteken.

M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 13 Jahren

Hallo FZelle,

entschuldige bitte: ja, ich meinte die DataTable.

Ich möchte dass die Anwendung später auch noch dann erweiterbar und übersichtlich ist, wenn sie einmal sehr groß wird, ohne etwas umzuschreiben.

Folgendes mag ich an den vorhandenen OR-Mappern nicht:

  • Es gibt eine Vielzahl davon und man weiß nicht, ob die Entwicklung daran später einmal eingestellt wird.

  • Es können scheinbar nicht alle Sachen damit gemacht werden. Ich suche aber eine Möglichkeit, die mir später einmal alles erlaubt.

  • Ich könnte später beim eigenen OR-Mapper meine eigenen Zugriffsmethoden wie gewünscht optimieren

Trotzdem sehe ich mir gerade auch Linq2Sql an, was scheinbar sehr viel einfacher ist. Wäre dies evtl. doch für mich sinnvollste Weg, den Du mir empfehlen würdest? (Auch wenn meine Anwendung später sehr wächst, ich evtl. einmal außer SQL-Server auch MySQL und Oracle einsetzen müsste?) Ich möchte dann gerne in der Datenzugriffsschicht einen Switch einbauen, der mir dann auch mit Linq2Sql je nach Datenbanksystem die richtigen Daten liefert.

Vielen Dank!

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]

F
10.010 Beiträge seit 2004
vor 13 Jahren

Da fängst Du aber am falschen Ende an.

Jetzt schon die Anwendung so zu designen, wie sie in 10 Jahren sein könnte ist der sichere Weg dazu, das sie niemals funktioniert, geschweige denn Fertig wird.

Wenn es tatsächlich so ein Grosses Projekt werden sollte, musst Du Dich erstmal mit Architektur im Allgemeinen beschäftigen.
Also was wird gemacht, Client/Server, Thin Client, FatClient, SmartClient, WPF, MVP, MVC, MVVM, SOA, WCF und viele weitere Sachen sind dann viel wichtiger.

Durch die mächtigen Refactoringmöglichkeiten von VS.NET und verschiedenen Addins ist
es dann im nachhinein immer möglich solche Sachen auszutauschen, wenn man vorher vernünftig Architektur betrieben hat.

Und was Du beschreibst nennt sich NIH Syndrom.

79 Beiträge seit 2005
vor 13 Jahren
  • Ich könnte später beim eigenen OR-Mapper meine eigenen Zugriffsmethoden wie gewünscht optimieren

Nur das ich das richtig verstehe: Um spätere Projekte zukunftssicher zu machen willst du jetzt viel Zeit in einen eigenen OR-Mapper investieren? Was meinst du, wieviel Zeit du mit deinem aktuellen Wissen investieren musst, um einen brauchbaren Mapper, welcher auch nur ansatzweise den Umfang von NHibernate oder LINQ2SQL bietet, umzusetzen?
Und das dann vorallem aus der Ungewissheit heraus, daß es einen aktuellen ORM dann nicht mehr gibt bzw. nicht mehr gepflegt wird? Glaubst du, Microsoft wird in .NET Version X.Y die ORM-Funktionen ersatzlos streiben und auf älteren Versionen erstellte Software lässt sich absolut nicht mehr migrieren?
Ganz ehrlich: Ich weiss meine Zeit besser einzusetzen als aufgrund zweifelhafter Hypthesen da rad nochmal zu erfinden.

roses are #FF0000 violets are #0000FF
all my base are belong to you

M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 13 Jahren

Hallo FZelle und Kenchu,

in der Tat habt ihr beide Recht und ich finde es toll, das ich durch diese Antworten nun auf dem (hoffentlich) richtigen Weg bin!

Ich habe mir Linq2Sql angesehen und stelle fest, das es wirklich ein sehr brauchbarer und einfacher OR-Mapper ist, der mir auch sehr(!) viel Arbeit abnimmt. (NIH-Syndrom damit hoffentlich kuriert)

Ich weiß, ich setze mich nun bestimmt viel Kritik aus, aber ich möchte vorerst kein "echtes" Schichtenmodell und erst Recht kein MVVM-Modell nutzen. Ich möchte in einem Projekt die "Schichten" vorerst als einzelne Klassen modellieren, aber den Zugriff der Schichten untereinander nicht verweigern, um die Anwendung einfach zu halten. (KISS) So komme ich am Anfang vorerst am Weitesten.

Die Anwendung soll entweder auf einem Rechner oder von mehreren Clients in einem Netzwerk aus genutzt werden.

Linq2Sql wird in der untersten "Schicht" eingesetzt.

Noch eine letzte Frage zu Linq2Sql: Empfehlt ihr über "LINQ to SQL-Klassen" den "grafischen Designer" (mit .designer.cs-Datei) zu nutzen oder die Entity-Klassen selbst schreiben? (Habe ich auch bereits erfolgreich gemacht und ist für mich zur Zeit etwas übersichtlicher)

Vielen Dank

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]