Ich dachte, dass ich nicht explizit darauf hinweisen muss, dass das abgeaenderte Dictionary lediglich eine Moeglichkeit von vielen ist, bevor man in Richtung ICommand geht und ohne, dass der eigentliche Use Case geschildert wurde.
@FZelle: Warum Du einen Knopf an der Backe moechtest oder hast, entzieht sich meinem Verstaednis, da das schon ziemlich doof aussieht. Aber das muss letztendlich jeder fuer sich entscheiden, welchem Schoenheitsideal man folgt.
Beste Gruesse
Moin, moin,
naja...man kann ICommand nehmen oder koennte das Dictionary auch auf Dictionary<string, Delegate> umschreiben (siehe Hinweis von Th69).
Gruss,
Moe
Moin,
Dein erstes Beispiel erzeugt erst einmal eine Instanz der SerialPort Klasse, wie Du bereits gesagt hast. Auf diese Art und Weise kannst Du bspw. eine lokale Variable in einer Methode erzeugen.
Die zweite Variante definiert zum einen die Sichtbarkeit "private" der Variable serialPort, und ist nur innerhalb einer Klasse sichtbar. Static bedeutet wiederum, dass jede neue Instanzen der umschliessenden Klasse Zugriff auf dieselbe Kopie der SerialPort Instanz hat. Die Variable serialPort ist Instanz uebergreifend gueltig/verfuegbar.
Gruss,
Moe
Moin,
letztendlich ist es ein Baum, der hier aufgebaut werden muss und man sucht nach dem kuerzesten Weg. Dazu faellt mir der A* (A-Stern) Algorithmus ein:
Vielleicht hilft Dir das weiter.
Gruss,
DaMoe
Hallo hasan,
ich wuerde zu LaTinos Punkten gerne den Punkt 0 hinzufuegen und Dir raten sich Gedanken ueber ein Domaenenmodell zu machen, d.h. brauchst Du eventuell eine Produkt-Klasse (mit Name und Preis; spaeter erhaelt es weitere Eigentschaften). Dann wirst Du sicherlich eine Warenkorb-Klasse benoetigen, die Produkte und deren Anzahl aufnehmen kann. Des weiteren wird sie dir dann die Summe bspw. ausgeben koennen usw.
Im Prinzip ist das Domaenenmodell die Grundlage fuer die technischen Punkte 1 und 2, die LaTino erwaehnt.
Gruss,
DaMoe
Huhu Angel123,
schau doch einfach mal hier. Vielleicht hilft Dir das weiter Testing if a device is in range
Gruss,
DaMoe
Hi Maliko,
das Szenario, welches Du beschreibst hoert sich nach Master-Detail DataGrid an. Schau mal hier, ob das was fuer Dich ist: Master-Detail-Wpf
Gruss,
DaMoe
@FZelle: Mit Auditing meinte ich lediglich Aktionen, die der User in einer Applikation durchfuehrt, d.h. Dinge selektiert, Aktionen ausfuehrt, Buttons klickt etc., sodass man einen groben Pfad durch die Applikation erhaelt. Das entscheidende an dieser Stellt soll aber nicht der Begriff sein. Ich meinte also das, was Du umschrieben hast mit:
Das ViewModel in MVVM ist die Businesslogik des View.
Wenn hier etwas zu loggen ist, was nichts in der darunterliegenden Schicht zu suchen hat, dann ist es natürlich die richtige Stelle.
Gruss,
DaMoe
Hallo zusammen,
mich interessiert eure Ansicht bzgl. Logging/Auditing in ViewModels. Wir haben eine Diskussion bei uns darueber, ob nun Logging Funktionalitaet in einem ViewModel verwendet werden darf oder nicht.
Eine Meinung dazu ist, da das ViewModel "zur UI gehoert", dass dort Logging nicht zu suchen hat. Ich sehe das etwas anders. Meiner Ansicht nach bildet das ViewModel u.A. Use-Cases ab, die man auf einer grob granularen Ebene "mitloggen"(Auditing) kann.
Wie seht Ihr das? Habt Ihr irgendwelche Literatur/Links zu Pro und Contra?
Selber habe ich mal u.A. bei Prism geschaut, wie die das machen.
Gruesse,
DaMoe