Ich arbeite seit einiger Zeit an einer Windows Forms-App und finde wirklich mehr Typumwandlungen im GUI-Code als je zuvor in meinem zugrunde liegenden Geschäftscode.
Was ich meine, wird offensichtlich, wenn Sie das ComboBox-Steuerelement betrachten, das ein vages "Objekt" als Item akzeptiert. Dann gehst du ab und kannst DisplayMember und ein ValueMember anzeigen und so weiter.
Wenn ich diesen Wert später abrufen möchte, muss ich mein Objekt zurückschreiben, was es war. Wie bei Strings bekommt man den Wert
%Vor%Da es seit geraumer Zeit Generics im Framework gibt, frage ich mich immer noch, warum in der Hölle nicht ein Control aus der Standard-Toolbox generisch ist.
Ich finde auch, dass ich die .Tag -Eigenschaft auf ListViewItems immer benutze, um das angezeigte Domain-Objekt zu behalten. Aber jedes Mal, wenn ich auf dieses Objekt zugreifen muss, brauche ich eine weitere Typumwandlung.
Warum kann ich nicht einfach eine ComboBox oder ListView mit Elementen vom Typ ListViewItem
erstellen?Fehle ich hier etwas oder ist das nur ein weiteres Beispiel für nicht perfekt durchdachte Kontrollen?
Während die Kritik von "Generics nicht verwenden" nicht auf Kontrollen angewendet werden kann, die vor ihrer Existenz entwickelt wurden, muss man sich über WPF-Controls wundern (neu in .NET 3.0, nach Generics in .NET 2.0).
Ich habe die Methode AddChild in ComboBox . Es braucht einen Objektparameter (ugh).
Dieses Steuerelement soll hauptsächlich über XAML verwendet werden. Wurde dies auf diese Weise gemacht, weil es keine Möglichkeit gibt, einen Typparameter in XAML anzugeben? (Abgesehen davon, gibt es keine Möglichkeit, einen Typparameter in XAML anzugeben?)
Es tut uns leid, dass wir keine definitive "Warum" -Antwort haben, sondern teilen uns nur das übliche Elend, dass wir beim Arbeiten mit der Benutzeroberfläche casten müssen.
Eine häufige Ursache für dieses Problem, denke ich, trennt Ihre Ansichts- / Darstellungslogik nicht von Ihrer In-Memory-Datenmodelllogik. Was leider ein Architekturfehler ist, an dem WinForms und der GUI-Designer von Visual Studio beteiligt sind.
WinForms und der VS-Designer ermutigen den Programmierer nicht, die Verwaltung ihrer Datenobjekte von den Formularklassen selbst zu trennen. Es wäre wahrscheinlich besser, wenn die ListViewItem-Objekte von ComboBox keine Unterstützung für beliebige Objekte bieten würden, weder über Generika noch über Object-Collections.
Wenn Sie nicht gerade etwas von begrenzter Nutzung und Lebensdauer hacken, sollten Sie vermeiden, Verweise auf einzelne Datenobjekte direkt in Ihren Steuerelementen oder Formularen zu speichern. Sie sollten separat verwaltet werden, und wenn sie referenziert werden müssen, sollte dies über eine Modellverwaltungsklasse erfolgen, die für den bestimmten Typ der Darstellungsklasse entwickelt wurde, mit der Sie arbeiten.
Eine einfache Binde für das Problem besteht jedoch möglicherweise darin, die Textdarstellungen, die Sie in die ComboBox oder ListView einfügen, mit einem Dictionary-Feldelement in der Form-Klasse den Originalobjekten zuzuordnen. Es ist keine ideale Lösung, aber Sie erhalten mindestens einen halben Schritt der Umleitung zwischen Ihren Daten und Ihren UI-Steuerelementen, wodurch der Code einfacher zu pflegen ist.
Bearbeiten: Dies ist zwar getrennt von der ListViewItemCollection-Klasse, die Objektinstanzen ausstellt ... Die offizielle Verteidigung besteht wahrscheinlich darin, dass sie die IEnumerable- und ICollection-Standardschnittstellen unterstützen wollten. Aber es gibt keinen Grund, warum sie auch typspezifische Überschreibungen dieser Methoden nicht bereitstellen konnten, da sie explizit zum Speichern von ListViewItem-Instanzen entworfen wurden. Also habe ich keine Antwort auf diese spezielle Frage.
Nun, wenn Sie Ihre Steuerelemente an eine DataBindingSource binden, können Sie Ihre Daten auf diese Weise erhalten, aber AFAIK, das immer noch nicht stark typisiert ist. Wenn Sie mehrere Parameter / Aspekte eines einzelnen Geschäftsobjekts anzeigen, können Sie sich daran binden und dann auf die (stark typisierten) Mitglieder zugreifen - natürlich geht das alles auf die Antwort von Turbulent Intellect zurück, die eine bessere Trennung zwischen Modell und Aussicht. Dennoch stimme ich zu, dass die generische Typisierung helfen würde.
Es ist möglich (Sie können Ihre eigenen generischen Steuerelemente erstellen, wenn Sie möchten), aber der Formular-Designer, der mit Visual Studio geliefert wird, wird ausflippen, wenn Sie dies tun. Sie müssen Sachen ohne es tun.
Sie sind nicht der Erste, der darüber nachdenkt, und Microsoft hat dafür bereits eine gehörige Menge an Kritik aus der Öffentlichkeit erhalten. Hoffen wir, dass sie dies in Zukunft unterstützen.