Hallo,
ich habe folgendes Problem: Es existiert ein HierarchicalDataTemplate dessen ItemsSource die Children Property (IEnumerable) des dahinterliegenden ViewModels anzeigen soll...und zwar sortiert nach der DisplayName-Property der Children-Objekte. Nun würde ich gern im Xaml eine CollectionViewSource definieren, die folgendermaßen aussieht:

<CollectionViewSource Source="{Binding Children}" x:Key="_source">
  <CollectionViewSource.SortDescriptions>
    <scm:SortDescription PropertyName="DisplayName" Direction="Ascending" />
  </CollectionViewSource.SortDescriptions>
</CollectionViewSource>

Das DataTemplate soll dann folgendermaßen aussehen:

<HierarchicalDataTemplate x:Key="_treeViewContainerTemplate" ItemsSource="{Binding Source={StaticResource _source}}"> ...

Nun wird leider die CollectionViewSource nur einmal erstellt bei dem ersten ViewModel, welches an das Template gebunden wird und ich bekomme einen TreeView, welcher ineinandergeschachtelt immer dieselben Items anzeigt. Wie schaffe ich es (im Xaml -> im Code gehts, ist aber unschön), dass die CollectionViewSource jedesmal "neu erstellt" wird???

Vielen Dank für eure Hilfe!

Hallo, also erstmal würde ich die Elemente nicht umbenennen, jedenfalls nicht so, wie du das vorschlägst. Englisch und Deutsch...das beisst sich in meinen Augen ganz stark.

Nun musst du was anderes verstehen. Es gibt nicht "die" vier entry-Elemente...es ist 4x das gleiche Element vom gleichen Typ. Du kannst hier weder die Reihenfolge der Eingabe definieren (Sie unterscheiden sich ja nur aus den dynamisch einzugebenen Werten), noch kannst du definieren, welche Werte Sie erhalten dürfen. Wenn du also genau 4 Elemente, in evtl. einer best. Reihenfolge, mit unterschiedlichen Datentypen willst (In dem Fall wohl ein echter Vorteil, da du dir auf Client-Seite lästige Typprüfungen sparen kannst), so solltest du dir 4 Elemente definieren und diese verwenden (aber bitte konsistent was die Sprache angeht).

Wie ja schon festgestellt, macht es wenig Sinn, auf DB Seite noch eine Stored Procedures Schicht zwischen zu ziehen. Damit macht man sich abhängig von einer DB, da alle ihre eigene Skriptsprache verwenden, bzw. manche DBs dies gar nicht unterstützen. Die korrekte Variante zur Problemlösung wurde auch schon genannt, nämlich die Normalisierung des Schemas, was einerseits saubereres DB-Design ist und einem zweitens mehr Flexibilität bei Abfragen gibt.

@Fzelle

Bin absolut bei dir. Ich kann nur nicht den Abschnitt in meinem Post finden, der sagt, dass Refactoring per se was schlechtes ist. Ich sagte nur, dass es im "Optimalfall" nicht notwendig ist. Wie oft tritt der Optimalfall ein? Richtig....so gut wie nie. Und deshalb ist Refactoring ja, wie ich auch geschrieben habe, sinnvoll zur Verbesserung der Codequalität.

Hallo Floste,
deine Fragen sind falsch gestellt. =) Das kommt immer auf den Anwendungsfall an. Es gibt Fälle da bringt Refactoring eine Menge und es gibt sicherlich auch Fälle in denen es nur minimale Qualitätsgewinne bringt (dann spart man sich das ganze).
Es bringt auf jeden Fall etwas, wenn du merkst, dass dein Design die Anforderungen nicht mehr abdecken kann. Dann sollte man refaktorieren. Es kann auch etwas bringen, wenn die die Beerbungshierarchie klarer gestalten willst, also bspw. um Redundanzen zu entfernen.
Bei uns ist Refactoring genau dann nötig, wenns nötig ist. 🙂 Optimalerweise sollte es nie nötig sein, denn dann hat man an irgendeiner Ecke nicht weit genug oder korrekt gedacht. Aus Erfahrung kann ich sagen...in Geschäftsanwendungen ist es eher selten notwendig, da die Anforderungen größtenteils von Anfang an klar sind. Bei der Frameworkentwicklung ist das bspw. anders...hier ergeben sich oft Anforderungen während der Entwicklung und dann kann es passieren, dass ein Refactoring Sinn macht.

my 2 cents

Was spricht gegen Serialisierung??? Würde ich in diesem Fall genau so machen.

Ich will mich wirklich nicht mit dir streiten. Bedenke bitte aber, dass Datenbanken noch viele andere Zwecke erfüllen, als "Objektdaten" (sei es von einem Kunden) zu speichern. Das ist wirklich nur ein kleiner Ast von dem, was Datenbanken können. Und nun schönes WE!!!

der pauschalen Aussage meines Vorredners möchte ich erstmal widersprechen.
welche pauschale Aussage meinst du - das untypisierte Objekte nicht programmierbar sind? (was anderes pauschales ist glaub nicht drin).
Jo, und da zeigt auch der genannte Link im Abschnitt DataReader, dass das erste was er macht, die Reader-Daten in eine Klasse namens Dinner zu überführen, ganz im Sinne meiner pauschalen Aussage.
Ob man nun typisierte Datasets nimmt, Link2Sql, EntityFramework, NHybernate oder was handgecodetes mit DataReader...

Mein Kommentar war in keinster Weise diskriminierend gemeint. Ich meinte eigentlich folgende (pauschale) Aussage:

Nur mit DBCommands kann man keine vernünftige DB-App schreiben ...

Das halte ich für, sagen wir mal, gewagt, so eine Aussage zu treffen. Aber wie ich schon erwähnte, ist da bei mir auch viel persönliche Vorliebe mit dabei. Ganz nebenbei ist der SqlDataReader ja nicht untypisiert, sondern bietet auch entsprechende Methoden an, Spaltenwerte einer Zeile typisiert zu erhalten. Wer mit SQL auf seine DB zugreift kennt das Schema und die Datentypen der Intension. Wie ich auf die Daten der DB zugreife, und da bleibe ich bei meiner Meinung, hängt sehr viel von persönlichen Präferenzen ab. Und da nutzt du eben gern DataSets (meine ich heraus zu hören) und ich eben das "altmodische" SqlCommand in Verbindung mit einem Reader. 🙂
Übrigens...das überführen der Daten im Beispiel in ein Objekt vom Typ Dinner ist dort natürlich die Präferenz des Programmierers und hat nichts mit dem Reader selbst zu tun. Im Fall von lorha, der ja evtl. nur wissen möchte, ob ein Eintrag existiert, reicht natürlich schon ein ExecuteScalar() beim SqlCommand und ein Verzicht auf jegliche Hilfsmittel. Alternativ kann er einen Reader über ExecuteReader() erzeugen und sich den Wert des von mir vorgeschlagenen Select Count(*) per GetInt16() zu holen. Da ist keine Objektkapselung nötig (beim Reader sowieso nie).

Was diese Thematik angeht (der pauschalen Aussage meines Vorredners möchte ich erstmal widersprechen. warum? -> siehe folgenden Link), so empfehle ich mal folgenden Blogeintrag zum Lesen:

Five NerdDinners

Von DataSets kann ich persönlich auch nur abraten. Ich bin auch noch ein Verfechter der guten alten DataReader. Aber EF4 und NHibernate ist auch was feines.

Ohne dich zu sehr verwirren zu wollen: Überlege auch, was du mit deinem SQL Statement erreichen willst. Brauchst du die User-ID, so selektiere diese auch nur im SELECT. Willst du nur wissen, ob überhaupt ein Datensatz vorhanden ist, der zu den eingegebenen Daten passt, verwende lieber ein "Select Count(User_ID) ... usw.". Das wird die Anwendung nicht richtiger machen, aber du lernst dabei, was es mit einer Datenbank auf sich hat. In "professionellen" Umgebungen wirst du das evtl. mal brauchen können (das Wissen).

MFG