Hallo JKruse,
vermutlich verwendest du für den Dialog und das Hauptfenster 2 verscheidene ViewModel-Instanzen.
Wenn dem so ist, müsstest du die ausgewählte Theme-Property des HauptFensterViewModels nochmal setzt damit auch für diese Instanz das OnPropertyChangedEvent geschmissen wird.
Gruß
Weiterhin kannst du in einem Int32 keine Telefonnummern speichern die mit 0 beginnen.
Hallo MrSparkle,
... Wenn diese Schritte uns jetzt von den Computer abgenommen werden ...){gray}
Nur weil der Computer hilft diese Informationen zu bekommen, bedeutet das nicht, dass man weniger lernen muss.
Du musst trotzdem lernen wie man z.B. das Molgewicht aus der Strukturformel eines Molekül ableitet, und dass lernt man nunmal nur indem man es anwendet. Später, in der "täglichen Arbeit" kann man dann Hilfsmittel verwenden. Aber das was in der Schule gelehrt wird, sollte meines erachtens nicht durch solche technologischen Fortschritte verändert werden.
Viele Grüße,
Tachyon
Donnie Darko
Pulp Fiction (Sry herbivore, aber einer der besten Filme kann nicht oft genug genannt werden ;P)
Trainspotting
Falling Down
Reservoir Dogs
American Beauty
Pi
The Big Lebowski
Requiem for a Dream
Fight Club
Adams Äpfel
Four Rooms
Fear and Loathing in Las Vegas
Was noch nicht genannt wurde:
Barry Lyndon
Wege zum Ruhm
Spun
Hallo waldemar,
Wieviel Dateien hast du denn in der Applikation?
Wie soll das Matching zwischen den Dateien statt finden?
Wie groß ist so eine Datei im Schnitt?
Die MD5Summe unterscheidet sich doch für unterschiedliche Dateien!?
Von daher würde die, wenn du Updates durchführen willst, schonmal als "Match"-Kriterium weg fallen . (Oder ist die MD5Summe eine Art ID die sich nicht direkt aus der Datei ergibt?)
Generell würde ich das alles in der Datenbank machen. Eine Datenbank ist doch genau dafür gedacht um schnelle Suchen, Dateneingaben usw. durchzuführen. Von daher sehe ich keinen Grund 100.000 Dateien in den Speicher zu laden um dort irgendwelche Operationen durchzuführen die die Datenbank viel besser kann 😉.
Viele Grüße,
Tachyon
Hallo mfe,
Ein Delegate vom Type Predicate<T> ist nicht dafür geeignet um Daten zu manipulieren.
Vielmehr ist es dafür gedacht, um zu bestimmen ob eine Bedinung für ein Objekt erfüllt ist oder nicht.
Schau dir mal Beispiele für Delegates vom Typ Action<T, ...> an. Das dürfte dir weiter helfen.
Schöne Grüße
Hallo gdata,
wenn das Projekt nicht zu groß ist könntest du dir mal SQLite mit dem entsprechenden Provider für .Net anschauen. Es gibt auch ein FireFox-Add-On um die Datenbank zu managen.
Das ist zwar alles recht einfach gehalten und nicht für größere Projekte gedacht. Aber ich denke als "Standalone"-Datenbank für kleine Projekte durchaus einsetzbar.
Grüße
Hallo Mr Evil,
- wie sollte ich diese "library.dll" am besten benennen ?
Das ist Geschmackssache und kommt auf den Kontext an.
Ich würde es so machen, dass alle Projekte einen kontextbezogenen Prefix bekommen. Für berufliche Projekte z.B. den Firmenname. Die Assemblies der verschiedenen Projekte würden dann beispielsweise heißen:
- <Firmenname>.<Projekt1>.dll
- <Firmenname>.<Projekt2>.dll
- ...
Basisklassen, die in allen Projekten verwendet werden können, würden dann in ein Assembly namens <Firmenname>.dll kommen.
Die Benamung kann dann z.B. noch über Abteilungsnamen o.ä. verfeinert werden.
Vielleicht noch ein Vorschlag zur Organisation der Klassen in Namespaces:
Ich würde mir da ganz Konsequent das .Net-Framework zum Vorbild nehmen. Die Klassen dort sind sauber und durchgängig organisiert, da kann man sich gut dran orientieren.
Beispiele:
Alle WPF-Controls kommen nach
<Firmenname>.<Windows>.<Controls>
Alle abstrakten Controls komme nach
<Firmenname>.<Windows>.<Controls>.<Primitives>
Alle Datenklassen nach
<Firmenname>.<Data>
usw...
Ich würde sogar soweit gehen und die Controls welche in den konkreten Projekten erstellt werden in die selben Namespaces packen (Also nach dem Firmennamen nicht nochmal den Projektnamen im namespace aufführen). Das hat den Vorteil, das man alle Controls hat, sobald man <Firmenname>.<Windows>.<Controls> einbindet. Man mus nicht überlegen wo genau das gesuchte control war, und jedesmal unmengen von Namespaces einbinden. Außerdem hat man ja durch die Verwendung des .Net-Frameworks schon ein Gefühl dafür wo welche Klassen zu finden sind. Das heißt, dass man selbst (und vor allem auch andere Entwickler) sich in der Struktu schnell zurecht finden werden.
Schöne Grüße,
Tachyon
Das ganze MVVM-Pattern ist für mich Präsentationsschicht, ein Zugriff auf die eigentliche Businesslogik erfolgt über eine separate Schnittstelle.
Genau das ist auch mein Verständnis. Das ViewModel bildet eine Art "Wrapper" um das Model und die Businesslogik und bereitet die Daten / die Funktionalität soweit auf, dass die View damit umgehen kann.
Hallo meisteralex ,
zum ViewModel gehört er meiner Meinung nach auch nicht, da er keine direkte Auswirkung auf irgendwelche (business)logischen Vorgänge hat, sondern nur indirekt durch seine Aktionen auf eine Liste wirkt, welche z. B. eine Collection steuert
Wenn der "Löschbutton" Items aus einer Collection entfernt hat das imho nichts mit der View zu tun und ist ganz klar Logik welche ins ViewModel gehört. Von daher würde ich die Logik des Buttons in ein Command auslagern und dieses and den Button binden (So wie es das MVVM-Pattern vorsieht).
Sprich, der eigentliche Button gehört zur View, die Logik die ausgeführt wird wenn der Button betätigt wird gehört ins ViewModel.
Schöne Grüße,
Tachyon