2009-07-30 8 views
3

Je veux diviser mon projet de vues en plusieurs modules. je veux avoir un projet principal qui aura ref à tous les modules et ce projet principal générera la vue à partir des modules.comment diviser la vue en modules dans m-v-vm

ma question est comment puis-je lier tous les styles de l'application aux autres modules?

le reconnaîtra-t-il automatiquement?

et comment les modèles de modèle de vue seront localisés? parce que maintenant ils r dans un dictionnaire de ressources que je fusionne dans le app.xaml

où shpuld je les ai mis (je veux qu'ils soient dans leur projet de module), comment puis-je charger ces ressources?

Répondre

1

Ce que vous voulez est facile à réaliser si vous utilisez Prism: http://www.codeplex.com/CompositeWPF

Il y a beaucoup d'échantillons pour vous lancer là-bas.

La seule question que vous posez qui ne répond pas par Prism est le ResourceDictionaries, mais il y a plusieurs façons de contourner cela, mais je pense que cela est la meilleure façon: Composite WPF (Prism) module resource data templates

La première réponse devrait vous aider Là. Vous perdrez un peu de temps de conception dans vos modules, mais tout devrait se faire correctement au moment de l'exécution de cette façon.

+0

+1 pour le lien - une méthode intéressante. –

2

bonne question. Comme l'a dit Anderson Imes, vous pouvez utiliser Composite WPF, mais il existe une autre option plus simple qui est disponible récemment si vous utilisez le Managed Extensibility Framework (MEF). Il ya another question I asked sur la façon de faire exactement ce que vous parlez en utilisant MEF. Fondamentalement, il utilise les fonctionnalités d'extensibilité de MEF pour rendre les ressources applicatives extensibles, puis vos modules "étendent" les ressources de l'application avec leurs DataTemplates (Views). Ensuite, vous ajoutez simplement votre ViewModel à l'interface graphique où vous voulez, et WPF prend soin d'appliquer votre View. J'ai construit une application sur ce modèle et ça marche très bien. L'avantage de l'utilisation de cette méthode est que votre fichier app.xaml ne doit pas "connaître" tous vos modules View, et vous êtes libre de découper et de couper votre application comme bon vous semble (je préfère segmentez-le par caractéristique, puis par couche).

+0

Je ne suis pas d'accord avec le fait que l'App.xaml "connaisse" les vues du Module ... nous permettons simplement au module d'insérer ses propres ressources dans l'App.xaml. Est-ce que MEF contourne cette limitation d'une façon ou d'une autre (permet aux modules/plugins de styliser leurs contrôles sans référencer explicitement le dictionnaire de ressources dans les ressources de votre vue)? –

+0

@Anderson Imes - Oui. Si vous avez un App.xaml avec un dictionnaire fusionné d'autres dictionnaires de ressources, vous devez appeler les autres dictionnaires par leur nom (au moment de la compilation). Cependant, si vous suivez la méthode dans la question liée, alors les modules et les plugins peuvent insérer leurs dictionnaires de ressources au moment de l'exécution. –

+0

il ne va encore que les fusionner à l'exécution quand MEF charge ses plugins. La chose que vous gagnez ici est un modèle déclaratif vs impératif pour l'insertion de dictionnaires de ressources dans l'application. Il n'y a rien à compiler sur cette approche. Cela dit, c'est vraiment bien. –

Questions connexes