Les étapes finales en utilisant MVVM à découpler GUI de la logique métier?

Question

Tout récemment, je l'ai appris en utilisant MVVM à découpler GUIs du modèle sous-jacent. J'ai fini par apprendre autant que je pouvais convertir ma demande actuelle vers MVVM, et a largement réussi. Maintenant, je dois comprendre comment prendre réellement une interface graphique générée dans le mélange et l'utiliser à la place de mon interface actuelle, qui a été conçu dans Visual Studio. Je ne peux pas trouver des ressources sur le web pour faire ce aussi transparente que possible. Je voudrais savoir ce que vous avez tous fait et ont eu le travail pour vous.

Ma solution ultime serait quelque chose qui me permettrait de, lors de l'exécution, sélectionnez une peau à partir d'un menu et ont immédiatement le changement de l'interface graphique de l'actuel à un autre que l'utilisateur sélectionne. Quelqu'un peut-il me pointer à des postes qui expliquent comment faire?

Mon objectif actuel est moins ambitieux - je voudrais pouvoir ajouter mon nouveau GUI Blend dans mon projet Visual Studio et quand je compile, que le nouveau GUI apparaît Blend. Si je veux revenir à l'ancienne interface, je recompiler. Pour l'instant, c'est correct.

J'ai mon projet de mélange ajouté à ma solution VS2008, et ai établi pour être l'application de démarrage. Cela fonctionne très bien - si je lance l'application, mon nouveau GUI apparaît à la place de l'ancien. Le problème est maintenant qu'il a besoin de DLL qui sont en fait dans un autre dossier - le dossier bin \ débogage de l'application de démarrage d'origine. Suis-je censé quitter mon interface graphique d'origine que l'application de démarrage, et ensuite son codebehind App charger l'autre GUI?

En outre, chacune des interfaces graphiques respectif a besoin d'une référence à la ViewModel. Dans mon cas, je ne faisais que instancier dans ma classe actuelle GUI. Pour l'interface graphique Blend, j'instancié un là aussi, puisque seule une des interfaces graphiques sera actif. Est-ce là où quelque chose comme le cadre fédérateur devrait être utilisé?

Désolé toutes les questions éventuellement-incohérentes, mais je ne suis pas tout à fait sûr que je devrais passer d'ici. Je sens que je suis si proche de me prouver que MVVM est le moyen de passer d'un point de vue de l'interface graphique (je suis déjà vendu sur le bit de testabilité).

Answer 1

J'ai trouvé une erreur, où dans une partie de mon code, j'utilisais la mauvaise propriété pour obtenir au chemin de l'assemblage actuellement en cours d'exécution. Je suis maintenant en utilisant

System.Reflection.Assembly.GetExecutingAssembly().Location

Bien que cela fonctionne, il ne fonctionne que si je copie l'exe du bac de projet Blend \ dossier de débogage dans le dossier bin \ Debug mon application principale. Je dois vivre avec cela en utilisant un événement après génération, je suppose. J'étais tellement gâté depuis plusieurs mois de travail avec .NET, où je ne devais pas le faire (comme avant en C ++) parce que tous les ensembles référencés sont copiés automatiquement. Si je veux déboguer un code-behind, je dois aussi mettre l'exécutable à partir dans les paramètres du projet Blend, ce qui est gênant aussi bien, surtout lorsque vous travaillez sur différents ordinateurs où les chemins ne sont pas mis en place les mêmes. Toute suggestion ici serait également apprécié!

Answer 2

Tous les exemples que je l'ai vu passer dynamiquement l'apparence de l'interface graphique en utilisant une certaine forme d'échange ResourceDictionary. Quelques liens:

Dictionnaires de ressources charge XAML à l'exécution

WPF changer le thème / le style à l'exécution

L'espoir qui aide.