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

Wie sieht die entsprechende Code-Behind Datei aus? Insbesondere: Was macht die Implementierung des textBoxSearch_TextChanged Events???

Alles klar...habe verstanden.
Hast du dein Problem denn mittlerweile gelöst? Ansonsten wäre mir noch eingefallen (wenn die XML Datei immer gleich ist, also implizit oder sogar explizit einem Schema genügt), dass du die XML Datei doch deserialisieren könntest. Dann kannst du ganz einfach auf die entsprechenden Properties in den deserialisierten Klassen zugreifen. LinQ to XML kommt bei dir wg. der 2.0 Restriktion nicht in Frage.
XPath kannst du aber natürlich auch in .NET 2.0 verwenden! Stichwort XPathDocument oder auch die "große Variante": XmlDocument.

Hallo Torti,
erstmal wieder mehr Fragen von mir...aus welchem Grund kannst du denn keinen DB Server laufen lassen? Was ist da die Restriktion??? Warum soll die Größe unbedingt verringert werden...ist Speicherplatz bei dir knapp, oder ist das nur reiner "Perfektionismus"???

Kleine Anmerkung noch...mein Prof hat immer gesagt:"Access ist keine DB"...und meine Erfahrung zeigt mir persönlich...er hatte recht.
Der MS SQL Server ist wirklich eine gute DB und in der Express Version auch noch kostenlos, allerdings mit der Restriktion auf 4GB(???) Größe. Ansonsten kann ich als Open Source Variante noch PostgreSQL wärmstens empfehlen. Das ist eine vollwertige, sehr performante DB.

Welcher Art sind denn deine Abfragen??? Evtl. würde sich bei dir auch ein Column Store anbieten...wenn du also viel über Spalten aggregieren musst z.B. Kannst dich ja mal oberflächlich in die Thematik einlesen.

Hallo Torti,
was genau machst du denn mit den Daten? Generell kann man sagen, dass, wenn du sie archivieren willst, dann ist eine Klartextdatei sinnvoller. Sollen die Daten allerdings weiterverwendet, bspw. um Anfragen darauf zu fahren, dann ist natürlich eine DB die richtige Wahl. Das ist aber nur ein allgemeiner Hinweis...bei bestimmten Anwendungsszenarien kann das natürlich anders sein.

MFG

Hallo tentod,
was hat XPath mit der Version des .Net Framework, bzw. mit .Net überhaupt zu tun? Ich verstehe deinen Kommentar nicht.

Hallo,
in deinem XPath Statement greifst du doch schon auf ein Attribut zu. Was genau möchtest du denn erreichen? Ich persönlich finde die Selektion von Attributen (oder gleich deren Werten) über XPath sehr sauber und flexibel.

Hallo,
wenn du keine FK-Beziehungen hast, dann mach doch einfach ein DROP Table und kreiere die Tabelle danach neu. Außerdem würde ich nicht in einem foreach die Befehle einzeln an die DB schicken, sondern in einem Command, besser noch in einer Transaktion, zusammenfassen.