Data Access Layer

  • WPF

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Data Access Layer

    Hallo zusammen,

    ich erstelle derzeite eine WPF-Anwendung mit Zugriff auf eine Access-Datenbank. Die Datenbank besteht aus mehreren Tabellen (Gesangsbüchern), deren Namen bereits beim Start der Applikation über eine BindableCollection in eine ComboBox gelesen werden.

    Jetzt möchte ich folgendes umsetzen; je nachdem welche Tabelle/ Gesangsbuch in der ComboBox ausgewählt wird, sollen in einer zweiten Combobox die jeweiligen Liedernummern des Gesangsbuch zur Auswahl angezeigt werden, umd dann nach erneuter Auswahl den Liedertext in einem Label anzuzeigen. Mein erster Ansatz war, dass ich mit einem EventChange der ComboBox erneut auf die Datenbank zugreife (OleDbconnection), um die Liedernummern und dann die Texte auszulesen, allerdings gestaltet sich das in WPF mit MVVM nicht so einfach, da die Combobox-Events losgelöst von meiner Business-Logik (ShellViewModel.cs) in der .xaml.cs getriggered werden und ich dann keinen Zugriff auf die Daten hätte. Außerdem ist dieser Ansatz nicht der sauberste, denke ich. Es soll sich ja alles im ViewModel abspielen...

    Ich habe jetzt von einem Data Access Layer gelesen. Ich verstehe darunter, dass man z.B. die Datenbank in eine Collection/List einliest und dann von seiner Applikation darüber auf seine Daten zugreift. Ich denke, dass macht aus Perfomancegründen auch Sinn. Die Datenbank ist zudem überschaubar groß.

    Vllt. hat jemand einen Ansatz, wie ich das strukturiert (MVVM, etc.) und auch mit der besten Performance lösen kann!?

    Vielen Dank vorab für jede Anregung!

    Hi, danke für den Link. Du schreibst:

    Sone CollectionViewSource ist ganz fabelhaft, damit kann man auch filtern, gruppieren und sortieren.

    Aber leider geht das nicht über Bindings ins Viewmodel hinein, sondern allenfalls über CollectionViewSource-Events,
    die im Codebehind (in "MainWindow3.Xaml.vb") empfangen werden können.
    Letzteres ist dann ziemlich ungeschickt, denn nach dem MVVM-Pattern
    sieht man zu, dass User-Eingaben wie die Angabe eines Filterkriteriums
    im Viewmodel landen, nicht im Codebehind. Und wie teilt man nun der CollectionViewSource ihr Filterkriterium mit?

    Mit Bindings geht das nicht, denn CollectionViewSource ist kein DependancyObject


    Genau das ist mein Problem...ich sehe aber nicht, wie Du das in dem Beitrag gelöst hast. Deshalb war ja meine Überlegung die Datenbank in einen Layer zu packen, um dann über das ViewModel darauf zugreifen zu können.

    cry.baby schrieb:

    Es soll sich ja alles im ViewModel abspielen...

    Sehe ich auch so....

    Wenn ich deinen Text richtig verstanden habe ist das simples Binding. Kurz und Bündig hast du eine Combobox und je nach auswahl in dieser willst du in einer zweiten Combobox andere Items generieren.
    OK. Dann machst du in deinem ViewModel für die erste Combobox zwei Eigenschaften. Ich nenne diese mal MyCollection1 und MySelectedItem1. Die Combobox ist auf MyCollection1 gebunden und SelectedItem der Combobox ist auf MySelectedItem1 gebunden. Für die zweite combobox hast du genauso zwei Eigenschaften im ViewModel.

    Im Setter von MySelectedItem1 kannst du nun darauf reagieren das nun eine andere Auswahl getroffen wurde und die MyCollection2 daraufhin neu befüllen.

    Ich hoffe du konntest mir folgen.

    Grüße
    Sascha

    PS: Ich denke ich verschiebe den Thread mal in den WPF bereich, dort gehört er hin!!
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Nofear23m schrieb:


    Im Setter von MySelectedItem1 kannst du nun darauf reagieren das nun eine andere Auswahl getroffen wurde und die MyCollection2 daraufhin neu befüllen.

    Ich hoffe du konntest mir folgen.

    Grüße
    Sascha


    Hallo Sascha,

    danke für Deine Antwort. Vom Prinzip habe ich es verstanden aber wie genau kann ich im Setter von MySelectedItem1 darauf reagieren, dass eine neue Auswahl getroffen wurde, um die zweite Collection zu befüllen? Ich müsste im Setter eine Methode einbauen, um auf meine Access-Datenbank zuzugreifen. Geht das?...Jetzt wo ich die Frage stelle, fällt mir ein, dasss NotifyOfPropertyChange auch eine Methode ist und die ist ja auch im Setter eingebettet. 8| Das sollte eigentlich funktionieren, oder? Muss ich später gleich mal ausprobieren! Das wäre natürlich ne sehr elegante Sache! :D Ich hoffe, ich freu mich nich zu früh...

    Liebe Grüße cry.baby

    cry.baby schrieb:

    Jetzt wo ich die Frage stelle, fällt mir ein, dasss NotifyOfPropertyChange auch eine Methode ist und die ist ja auch im Setter eingebettet.

    Genau richtig erkannt.

    Und wenn du nicht bei jeder Zuweisung neu von der DB abrufen willst sondern nur falls sich der Wert wirklich geändert hat kannst du auch mit If Not _deinePRopertyVariable = value Then vorher abrufen.
    Ich verwende für derartige Dinge sehr gerne den Setter von "SelectedItem". Das ist eine sehr komfortable Sache im zusammenspiel mit Binding und finde ich persönlich auch übersichtlicher als "früher" in der CodeBehind mit Events.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    cry.baby schrieb:

    Hi, danke für den Link. Du schreibst:
    ...Mit Bindings geht das nicht, denn CollectionViewSource ist kein DependancyObject

    Genau das ist mein Problem...ich sehe aber nicht, wie Du das in dem Beitrag gelöst hast. Deshalb war ja meine Überlegung die Datenbank in einen Layer zu packen, um dann über das ViewModel darauf zugreifen zu können.
    Hmm - aber genau deswegen habich das Tut doch gemacht.
    Weil ich stelle dort eine Lösung dafür vor - vielleicht hast du nicht bis Ende gelesen?
    Und immer auch die Sources downloaden und laufen lassen.

    ErfinderDesRades schrieb:

    cry.baby schrieb:

    Hi, danke für den Link. Du schreibst:
    ...Mit Bindings geht das nicht, denn CollectionViewSource ist kein DependancyObject

    Genau das ist mein Problem...ich sehe aber nicht, wie Du das in dem Beitrag gelöst hast. Deshalb war ja meine Überlegung die Datenbank in einen Layer zu packen, um dann über das ViewModel darauf zugreifen zu können.
    Hmm - aber genau deswegen habich das Tut doch gemacht.
    Weil ich stelle dort eine Lösung dafür vor - vielleicht hast du nicht bis Ende gelesen?
    Und immer auch die Sources downloaden und laufen lassen.


    Ich habe es mehrfach durchgelesen aber noch nicht verstanden. Werde es mir in einer ruhigen Minute nochmal anschauen. Bin immer dankbar für neue Denkansätze.

    Was meinst Du genau mit 'Und immer auch die Sources downloaden und laufen lassen'?

    Üblicherweise enthalten meine Tuts immer einen Download-Link mit lauffähigen Beispiel-Anwendungen (nur Source-Code).

    Dieses downloaden, entpacken, die *.sln-Datei mit Doppelklick öffnen, kompilieren und ausführen ("laufen lassen").

    Jo - habich jetzt geguckt - der DownloadLink ist am Ende des ersten Posts.
    Und darin ist sicherlich der Code des Programms, wovons da ein Bildchen gibt, und sicherlich ist das auch im wesentlichen der Code, der im Tut besprochen wird.

    Nofear23m schrieb:


    Ich verwende für derartige Dinge sehr gerne den Setter von "SelectedItem". Das ist eine sehr komfortable Sache im zusammenspiel mit Binding und finde ich persönlich auch übersichtlicher als "früher" in der CodeBehind mit Events.


    Welche Szenarien gibt es in WPF mit Bindings eigentlich noch für Events? Mir fehlt da gerade bischen die Fantasie...

    z.b. Trigger in Verbindung mit AttachedProperties aber das sind dann eher speziellere Dinge.

    Ich habe aber auch schon gesehen das Leute Events in der CodeBehind abonnieren und sich dann in der CodeBehind das ViewModel über den DatenContext holen umd dann Prozeduren im VM anzustoßen.
    In gewissen Fällen ist das auch in Ordnung aber man sollte versuchen sowas zu vermeiden.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Also kann man schon sagen, dass Events weitestgehend nicht mehr wirklich gebraucht werden...

    CodeBehind abonnieren um über DatenContext Prozeduren in VM anzustoßen 8| -> das würde ich auch vermeiden wollen. In gewisser Hinsicht war es mit WinForms doch geradeliniger...

    cry.baby schrieb:

    In gewisser Hinsicht war es mit WinForms doch geradeliniger...

    Ich für meinen Teil finde Binding um einiges übersichtlicher.

    Das einzige wo sich manche schwer tun ist einfach das die Codedatei (in diesem Fall das ViewModel) nicht direkt unter dem Window/Control im SolutionExplorer ist sondern so anders.
    Aber sonst ist Binding ja viel besser. Ich muss mich um sooo vieles einfach nicht mehr kümmern. aber ist eben Geschmacksache.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    cry.baby schrieb:

    Also kann man schon sagen, dass Events weitestgehend nicht mehr wirklich gebraucht werden...
    Hmm - ich würde anders formulieren: Events sind schwierig zu handeln - und deshalb versucht man sie zu vermeiden.
    Mit dem CommandPattern ist ja eine Technik gegeben, die zumindest Click-Events (fast) jeglicher Art tatsächlich obsolet macht - die braucht man wirklich nicht mehr.

    Aber zB bei Drag&Drop muss man verschiedenerlei Mouse- und andere -Events verarbeiten - das ist ziemlich ungemütlich.