Java und Java FX muss aber immer fummeln was ich echt schade finde.
Daher habe ich bis heute noch keine GUI wie ich mir diese vorstelle.
Microsoft Visual Studio scheint mit dem WPF alles in einem Guss zu haben und möchte es mal damit versuchen. Nun habe ich Visual Studio 2019 und das Buch C# mit Visual Studio 2019 und mache mal die ersten Schritte.
Ob du bei WPF ohne fummeln auskommst ist allerdings fragwürdig. Ist schwer zu sagen was du dir vorstellst. Hab bisher noch nie mit einem GUI Frontend gearbeitet welches mir alle Wünsche von den Lippen abgelesen hat.
Warum braucht ihr an dieser Stelle hier den konkreten Typ ObservableCollection<T> ? Reicht euch ggf. auch das INotifyCollectionChanged als Interface ggf. in Kombination mit ICollection / IList?
Warum benötigt ihr Zugriff auf den konkreten Typen? Reicht euch ggf. nicht einfach davon auszugehen, dass Data eine IList ist ( wohlgemerkt ohne den generic Type ). Ihr könntet dann über Reflection den Generic Type der IList ermitteln und dann ebenfalls über reflection eure Properties ermitteln.
public static Type GetGenericTypeDefinitionOfIEnumerable(this Type enumerable)
{
return enumerable.GetInterfaces().Where(t => t.IsGenericType && t.GetGenericTypeDefinition() == typeof(IEnumerable<>))
.SelectMany(t => t.GetGenericArguments()).First();
}
Eine wichtige Frage wäre was für eine Art Verbindung du testen möchtest. Als einfachste Methode gilt hier eigentlich ein Ping auf den Server. Wenn du das für bestimmte Ports benötigst hilft dir ggf. dieser Stackoverflow post Ping a Specific Port
- Programmieren ist zum allergrößten Teil Erfahrung. Erfahrung erlernt man nicht aus Büchern (die sind aber natürlich trotzdem wichtig) und man muss viel Zeit mitbringen. Das Programmieren sein zu lassen würde ich dir also nur dann raten wenn es dir keinen Spaß macht. Ansonsten gilt: Bleib dran auch wenn es stellenweise frustrierend sein kann.
- Du glaubst Objektorientierung verstanden zu haben. Aber das ganze geht weit über die Verwendung von Objekten hinaus. Und auch die OOP ist kein Allheilmittel. Ich habe das Gefühl das dir ein Buch über Entwurfsmuster einen großen Schritt ermöglichen würde. Buchempfehlung hier: "Head first design patterns" ( wenn du es magst das Dinge wirklich einfach und verbildlicht erklärt sind ) oder "Design Patterns. Elements of Reusable Object-Oriented Software" ( mehr text aber eigentlich die bessere Lektüre ).
- Es ist gut wenn du fragst was andere über deinen Code denken. Das zeigt das du selbst reflektiert bist und Kritik zulässt. Das ist ein sehr wichtiger Faktor in der Softwareentwicklung. Bleib dabei von anderen etwas zu lernen und gib weiter was du selbst verstanden hast.
- Es gibt nur ganz selten den einen richtigen Weg. Gewöhne dir an darüber nachzudenken was für deinen Anwendungsfall gerade die beste Lösung zu sein scheint ( unter den dir wichtigsten Gesichtspunkten ). Du wirst merken, dass man nicht immer alle Vorteile eines Weges bekommen kann ohne andere Nachteile mit zu ziehen. Daher ist es wichtig sich zu überlegen was man erreichen will.
Von MySQL würde ich generell - wie eigentlich fast die gesamte Community - mittlerweile großen Abstand nehmen.
MariaDB ist ja zB aufgrund der politischen Problematik mit MySQL entstanden. Selbst in der PHP Welt gibts mittlerweile große Abstandsversuche von MySQL.
Hast du dazu etwas mehr Background? Vielleicht nen Artikel oder zwei die du gelesen hast? Hab davon gar nichts mitbekommen aber es würde mich interessieren wo die Probleme bestehen und wie sie entstanden sind.
Warum möchtest du in der ObservableCollection denn unbedingt Models haben?
Wäre es nicht logischer deine DeviceViewModels in dieser Collection zu halten und jedes DeviceViewModel ist der Container für ein Model? Damit sollte dein Problem der Hierarchie doch einfach lösbar sein?
ich kann jedoch nicht die Eigenschaften des Models abrufen, dessen Button auf dem ViewModel geklickt wurde.
Das musst du näher ausführen. Was ist dein Model ( Gerät? ). Wie willst du die Eigenschaften abrufen?
EIn Button wird nicht auf einem ViewModel geklickt. Du hast vielleicht einen Command in deinem ViewModel welcher per Binding auf einen Button in deinem DataTemplate gebunden ist.
Dein DataTemplate besteht hier jedoch nur aus einem Gerät Control. Das Control müsste man mal sehen.
Ich hoffe der Typ Gerät aus ObservableCollection<Gerät> entspricht nicht demselben Typ Gerät deines Controls ( local:Gerät ) ansonsten hast du etwas missverstanden bei MVVM Konzept.
Da wäre dann die Frage warum du sie explizit im Codebehind erstellen musst?
Erzeugst du aus deinen Daten entsprechende UI Elemente? Wenn ja ist hier das Konzept von DataTemplates und DataTemplateSelector im Zusammenhang mit ContentControl und ItemsControl vermutlich von Interesse.
Wenn die Abhängigkeiten deines Services im DI Container registriert sind, dann werden die Laufzeit automatisch aufgelöst. D.h. du musst nichts explizit übergeben.
Wenn also sowohl Context als auch Service beide als Typen im DI Container registriert sind werden die Abhängigkeiten zur Laufzeit auch vom DI Container automatisch erzeugt / wiederverwendet
Da wir jedoch ein Unternehmen ohne Projekte sind und eine eigene Produktpalette entwickeln ist bei uns eigentlich vom Homeoffice abgesehen alles beim alten. Da unsere Kunden Onlinehändler sind, ist sogar gefühlt fast mehr los als sonst.
In der Regel kannst du sowas über einen Bounded Context bzw. Aggregates lösen.
Es ist nicht so als müsste dein Autositz jemanden fragen wer der Fahrer ist, viel mehr müsste dein Auto mitbekommen wenn der Fahrer gewechselt wird ( oder wo auch immer ) und diese Information auch sofort an den Autositz weitergeben. Somit bleibt die Zuständigkeit beim Fahrerwechsel ganz eindeutig beim Auto.
Schau dir am besten die Thematik zum Domain Driven Design an und ergänzend kann ich außerdem das Prinzip des Data Oriented Design empfehlen.
Ich frage mich ja, warum ich da nicht gleich draufgekommen bin! Ich überlege, ob das nicht sogar sauberer ist; denn tatsächlich brauche ich ja nur den geänderten Wert! Die View selbst interssiert sich in meinem Fall gar nicht mehr dafür, was mit dem Wert passiert; so vom Gefühl her würde ich sagen, dass man vlt. auf das SelectionChanged-Event nur dann mit einem EventToCommand reagieren sollte, wenn dadurch eine Relevanz für die View gegeben ist (veränderte Darstellungsoptionen, etc). Da ich hier aber aus dem Bauch raus argumentiere, kann und will ich dafür nicht die Hand ins Feuer legen. Es würde mich aber schon interessieren, wie sich das verhält, oder ob es schlicht Wurscht ist.
Nochmals Danke, macht's gut,
Vorph
Am saubersten ist das was am ehesten deinem Usecase entspricht. Wenn du eine Aktion nur auslösen möchtest wenn der Benutzer über die UI eine Änderung an der Combobox vollzieht wäre es möglicherweise sauberer es über ein EventToCommand zu lösen.
Bedenke nämlich: Eine Änderung am Property innerhalb deines ViewModels würde dieselbe Bedeutung haben wie die Benutzerinteraktion aus der UI. Und manchmal möchte man dazwischen unterscheiden können.
Das magische Suchwort für dich lautet wohl EventToCommand. Unter diesem Begriff versteckt sich am häufigsten was du tun möchtest. Jedes gängige MVVM Framework hat dazu eine fertige Implementierung mitsamt der Einbindung der notwendigen Abhängigkeiten.
Das hier ist ein Beispiel mit MVVM Light. Eventuell ziehst du ja in Betracht ein bestehendes MVVM Framework zu nutzen anstatt selbst eines zu schreiben.
Ich glaube worum es Wasined hier ging ( zumindest habe ich das so rausgelesen ) ist das Tooling rund um das eingesetzte System. Das sollte aber natürlich nicht das Hauptkriterium sein bei der Auswahl der Technologie.
Wie du SQLite, als Framework, in deiner Wpf Anwendung unterbringst sollte durch ein paar kleinere Tutorials schnell abgefrühstückt sein. Empfehlenswert sind die automatischen Einbindungsmöglichkeiten über Toolings in Visual Studio sowieso meist nicht da man dazu verleitet wird sich keine Gedanken über die interne Softwarearchitektur zu machen.
Wenn es dir nur darum geht, dass du die Daten und Strukturen in deiner Sqlite Datenbank verändern und auslesen kannst ,ohne deine Anwendung zu nutzen, dann kann ich dich beruhigen. Dafür gibt es zahlreiche Tools im Internet mit denen du dies erreichen kannst. Es wird dann halt nicht direkt über Visual Studio laufen. Ich sehe das aber durchaus als Vorteil und nicht als Nachteil.
Ich habe meist SqliteExpert ( free edition ) oder Sqlite Administrator verwendet.
ich interessiere mich sehr für die Konzepte und Herangehensweisen der Spieleprogammierung in Unity 3D und suche daher nach einem guten Buch zum Lesen für unterwegs.
Was ich NICHT suche:
-------------------------
- Ein Buch was mir jede Funktion des Editors erklärt und was man damit machen kann.
- Wie baue ich mein erstes Spiel indem ich Code und Material irgendwohin lege und irgendwie ans laufen bekomme.
- Grundlagen in C#
! Was ich suche:
-------------------
- Toll wäre es wenn es von jemandem aus der Branche geschrieben ist der auch persönliche konkrete Erfahrungen und somit Do's and Don'ts vermittelt.
- Wie trenne ich am effektivsten meine Spiel logik von dem aktuellen Spielclient
- Einführung in Strukturierung von Spielinhalten, Vermittlung der Konzepte und Design Patterns dahinter.
- Worauf sollte man wachsenden Projekten achten und welche Probleme treten häufig auf. Wie kann man sie vermeiden?
Für jede Empfehlung bin ich dankbar :-). Bin bereits über dieses Buch gestolpert ( -> Game Programming Patterns (Englisch) Taschenbuch ) , jedoch habe ich die Befürchtung, dass es nur einen Bruchteil meiner eigentlichen Fragen beantwortet ( Welche Patterns es gibt )
Ich habe mit solchen impliziten Abhängigkeiten eher schlechte Erfahrungen gemacht und kann daher nur davon abraten. Was ich meine?
-> ViewModelA hat ein Property welches sich aus 2 oder mehr Properties zusammensetzt die woanders liegen.
Ich würde empfehlen: Schreib konkrete Logik die dein zusammengesetztes Property wirklich ändert wenn sich eine der Abhängigkeiten ändert. Dadurch musst du keine bestimmte Logik mehr nachziehen wenn es um Validierung o.ä. geht, denn dein PropertyChanged wird ja wirklich geworfen weil es sich geändert hat. Das hat auch den Vorteil der Nachvollziehbarkeit im Code.
Zu deiner eigentlichen Ausgangsfrage:
Ich würde das PropertyChanged Event von ViewModelB fangen und in der Behandlung dein Property welches scheinbar eine Abhängigkeit hat neu Berechnen und Zuweisen. Das ganze kannst du dann auch easy durch einen Unittest abdecken.
Das wichtigste aber ist, du baust eine explizite Abhängigkeit die man leicht nachlesen kann. Ich persönlich halte nichts davon wenn ein Property mehrere PropertyChanged Ereignisse für andere Properties wirft nur weil sich diese scheinbar an etwas bedienen.