myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Grundlagen von C# » CollectionChanged --> verschachteln oder eigenständig?
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

CollectionChanged --> verschachteln oder eigenständig?

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Moritz83
myCSharp.de-Mitglied

Dabei seit: 27.05.2013
Beiträge: 50


Moritz83 ist offline

CollectionChanged --> verschachteln oder eigenständig?

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Moin,

ich habe folgenden Ausgangssituation (WPF MVVM):
Auf einer View habe ich eine Listview und einen Button mit dem ich einen Eintrag aus der Listview löschen und danach die SQLite Datei aktualisieren möchte.

Das mit dem Binding des Buttons klappt soweit, allerdings habe ich ein Verständnis Problem wie der Hintergrund aussehen sollte. Meiner Meinung nach habe ich 2 Möglichkeiten:

C#-Code:
        public RelayCommand DeleteEmployee
        {
            get
            {
                command = new RelayCommand(Delete);
                return command;
            }
        }

1. Möglichkeit

C#-Code:
        public void Delete()
        {
            //aus Listview löschen
            //aus SQLite löschen
        }

oder ich gehe über die CollectionChanged Variante (eine ObservableCollection dient als Datenlieferant für die Listview) als

2. Möglichkeit

C#-Code:
EmployeeListView.CollectionChanged += new System.Collections.Specialized.NotifyCollectionChangedEventHandler
(CollectionChangedMethod);

C#-Code:
        public void Delete()
        {
            //aus Listview löschen und CollectionChanged triggern
        }

C#-Code:
        private void CollectionChangedMethod(object sender, NotifyCollectionChangedEventArgs e)
        {
            if (e.Action == NotifyCollectionChangedAction.Remove)
            {
                //Aus SQLite löschen
            }
        }

Würde jetzt die 1. Möglichkeit nehmen da sie mir "sauberer" erscheint, wie "sollte" man das lösen?
Neuer Beitrag 11.10.2019 12:13 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 14.201
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

In MVVM arbeitet man aber nicht mit Code Behind Eventhandling und damit auch nicht mit CollectionChanged.
 [Artikel] MVVM und DataBinding
Neuer Beitrag 11.10.2019 12:14 Beiträge des Benutzers | zu Buddylist hinzufügen
Moritz83
myCSharp.de-Mitglied

Dabei seit: 27.05.2013
Beiträge: 50

Themenstarter Thema begonnen von Moritz83

Moritz83 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Der Code steht auch in meinem ViewModel und net im Code Behind. Im Code Behind von MainWindow.xaml steht nur

C#-Code:
        public MainWindow()
        {
            InitializeComponent();
            DataContext = new EmployeeViewModel();
        }
Neuer Beitrag 11.10.2019 12:17 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 14.201
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Schau Dir MVVM an.

Das Control gehört da nicht in Dein ViewModel.
In das ViewModel gehören die Daten, die gebunden werden.

Und im XAML steht dann welches Control was bindet.
Du arbeitest mit Events - das ist in MVVM so nicht vorgesehen. Es ist eine Abhängigkeit, die man mit MVVM eben nicht will.

Aktionen werden dann zB. über Commands gelöst - aber nicht über Events.
Steht alles in dem Artikel.

Und so eine Aktualisierung würde man auch nicht über den Eintrag der UI-Elemente machen, sondern über die gebundenen Daten.
Neuer Beitrag 11.10.2019 12:32 Beiträge des Benutzers | zu Buddylist hinzufügen
Moritz83
myCSharp.de-Mitglied

Dabei seit: 27.05.2013
Beiträge: 50

Themenstarter Thema begonnen von Moritz83

Moritz83 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

entweder verstehe ich nicht was du mir sagen willst oder wir reden komplett aneinander vorbei. Hier ganz vereinfacht die Ausgangslage:

MainWindow.xaml

C#-Code:
<ListView Name="MuhKuh" ItemsSource="{Binding EmployeeListView, UpdateSourceTrigger=PropertyChanged}" SelectedItem="{Binding YourSelectedItem, Mode=TwoWay}" Height="86">
//Code
<Button Command="{Binding DeleteEmployee}" CommandParameter="{Binding EmployeesListView}" Margin="0,0,10,0">Delete</Button>
//Code
</ListView>

MainWindow.xaml.cs

C#-Code:
        public MainWindow()
        {
            InitializeComponent();
            DataContext = new EmployeeViewModel();
        }

----> Binding ---->

EmployeeViewModel.cs (RelayCommand ist eine eigene Klasse in einer eigenen Datei)

C#-Code:
//Definition der ObservableCollection für die View
//Code
//RelayCommand Definition
public RelayCommand DeleteEmployee
        {
            get
            {
                command = new RelayCommand(Delete);
                return command;
            }
        }

meine Frage wäre nun ob die Delete Void die ich aufrufe
a.) Das Löschen des Eintrags aus der ObservableCollection (die View kriegt durch das Binding ja automatisch ein Feedback) UND das Löschen des Eintrags aus der DB beinhaltet.

oder

b.) Das Löschen des Eintrags aus der ObservableCollection beinhaltet und die Funktion zum löschen des DB Eintrags in der SQLite Datei im besagten CollectionChanged Event steht

Sorry wenn ich mich vielleicht nicht klar ausgedrückt habe

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Moritz83 am 11.10.2019 12:57.

Neuer Beitrag 11.10.2019 12:56 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
MarsStein MarsStein ist männlich
myCSharp.de-Poweruser/ Experte

avatar-3191.gif


Dabei seit: 27.06.2006
Beiträge: 3.156
Entwicklungsumgebung: VS 2013, MonoDevelop
Herkunft: Trier -> München


MarsStein ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo,

auf jeden Fall Möglichkeit a.)
Und zwar in umgekehrter Reihenfolge: Erst löschst Du das Objekt aus der Datenbank (über ein entsprechedes Datenlayer), und erst wenn das funktioniert hat aus der ObservableCollection im ViewModel. Dann kannst Du auch noch Fehlerbehandlung machen, wenn das Löschen aus der DB schiefgeht, und das Objekt ist in der UI noch vorhanden.

Möglichkeit b.) ist ein völlig falscher Ansatz.
Wenn ein solcher Code

C#-Code:
EmployeeListView.CollectionChanged += new System.Collections.Specialized.NotifyCollectionChangedEventHandler
(CollectionChangedMethod);

im ViewModel auftaucht, bedeutet das, dass das ViewModel die View kennt und das sollte es nie.

Wenn der Code im CodeBehind steht, verlagerst Du Deine Löschlogik direkt unter Umgehung des ViewModels in die View - und das ist dann auf jeden Fall ein Designfehler.

Auf dieser Grundlage sind dann auch die Aussagen

Zitat von Abt:
In MVVM arbeitet man aber nicht mit Code Behind Eventhandling

Zitat von Abt:
Das Control gehört da nicht in Dein ViewModel.

hoffentlich verständlich, denn bei dem Ansatz über CollectionChanged trifft auf jeden Fall einer dieser Umstände zu.

Gruß, MarsStein
Neuer Beitrag 11.10.2019 16:23 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Th69
myCSharp.de-Poweruser/ Experte

avatar-2578.jpg


Dabei seit: 01.04.2008
Beiträge: 3.736
Entwicklungsumgebung: Visual Studio 2015/17


Th69 ist online

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Da ist die Benennung eindeutig schlecht, denn bei EmployeeListView handelt es sich (wohl) nicht um das UI-Element (denn dieses hat ja gar kein CollectionChanged-Ereignis), sondern um die Collection, an der die ListView gebunden ist (d.h. Employees o.ä. wäre ein besserer Name für diese ViewModel-Eigenschaft).

PS: Auch der von dir benutzte Ausdruck

Zitat von Moritz83:
Delete Void

deutet darauf hin, daß du anscheinend noch nicht so ganz in der Materie drin bist, denn du meinst wohl "Delete Methode"?! void ist ja nur der Rückgabewert dieser Methode (und bedeutet einfach "leer") - du sagst doch auch nicht "Delete Int" oder "Delete Float"?!

Aber diesen Ausdruck habe ich schon des öfteren bei Anfängern gelesen, da sie wohl davon ausgehen (wie in anderen, nicht auf C basierenden, Sprachen, daß dies so etwas wie "procedure" oder "function" bedeutet - und verwenden es daher fälschlicherweise als Synonym dafür).

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Th69 am 11.10.2019 17:47.

Neuer Beitrag 11.10.2019 17:41 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Moritz83
myCSharp.de-Mitglied

Dabei seit: 27.05.2013
Beiträge: 50

Themenstarter Thema begonnen von Moritz83

Moritz83 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@MarsStein
Super, danke für den Wink wie man so etwas angehen könnte. Auf die Idee mit der integrierten Fehlerbehandlung bin ich gar nicht gekommen, macht aber mehr als Sinn.

Klar, nun verstehe ich auch was Abt gemeint hat (wenn gleich das im ersten Augenblick vielleicht mehr als verwirrend war).

Merci für deine Hilfe und hilfreichen Tipps!


@Th69
Ja die Benennung ist wirklich schlecht in meinem Projekt. Hab da noch kein Händchen für. Meine Idee war erstmal ein funktionierendes "Etwas" auf die Beine zu stellen und mir dann Schritt für Schritt den Code durcharbeiten um eben sowas, als auch die von Abt und MarsStein angesprochenen Sachen zu ändern.

Bin definitiv noch ein Anfänger und habe tatsächlich nur Erfahrung mit Visual Basic (aber da auch eher Quick & Dirty als Ordentlich & Strukturiert). Ich habe natürlich die Methode gemeint.

Danke dir für deinen Input!

@Abt
auch dir vielen Dank (auch wenn ich Hilfe gebraucht habe um die Message zu verstehen ;) )

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Moritz83 am 11.10.2019 18:26.

Neuer Beitrag 11.10.2019 18:25 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
MarsStein MarsStein ist männlich
myCSharp.de-Poweruser/ Experte

avatar-3191.gif


Dabei seit: 27.06.2006
Beiträge: 3.156
Entwicklungsumgebung: VS 2013, MonoDevelop
Herkunft: Trier -> München


MarsStein ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo,

Zitat von Th69:
denn bei EmployeeListView handelt es sich (wohl) nicht um das UI-Element (denn dieses hat ja gar kein CollectionChanged-Ereignis), sondern um die Collection

In der Tat, da habe ich mich wohl von der Benennung hinreissen lassen - Freitag Nachmittag, puh!

Das bedeutet, was ich bezüglich Views geschrieben habe, trifft hier nicht zu, wir sind die ganze Zeit auf ViewModel-Ebene.

Trotzdem halte ich den Ansatz, über das CollectionChanged-Ereignis zu gehen, aus den ebenfalls genannten Gründen für den falschen Weg.

Gruß, MarsStein
Neuer Beitrag 11.10.2019 20:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 14.201
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top



Zitat von MarsStein:
In der Tat, da habe ich mich wohl von der Benennung hinreissen lassen

Same here.
Neuer Beitrag 11.10.2019 20:07 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 11 Monate.
Der letzte Beitrag ist älter als 11 Monate.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 26.09.2020 12:44