Structure de projet Prism v2 Silverlight / WPF recommandée

Question

Je suis actuellement chargé d’enseigner Silverlight (v2) à tous les développeurs de l’entreprise dans laquelle je travaille. Le seul problème est que je n'ai aucune expérience Silverlight. Bien sûr, j'ai étudié tous les détails techniques sur des choses comme la liaison de données, la mise en page, etc. afin de pouvoir aider mes collègues. Mais il est difficile de trouver des informations sur la structure générale du projet.

J'ai décidé de suivre le chemin P & P; P Prism 2 (et peut-être même d'ajouter un peu plus tard WPF dans le mix) et je me demandais donc si quelqu'un parmi vous, personnes intelligentes, avait de l'expérience dans le développement d'un vrai projet utilisant Prism 2 ou même simplement WPF, et si vous aviez des suggestions sur la structure de projet / solution? Par exemple, "Où mettez-vous les vues?" ou "Avez-vous des conventions de dénomination de projet de module?" etc.

Toute aide sera grandement appréciée.

Answer 1

Ceci est purement basé sur mon expérience d’utilisation de Prism pour WPF, et non de Silverlight. Je ne suis pas un expert chez Prism et je pourrais facilement changer d’avis sur certains d’entre eux. : -)

• Il est tentant de créer un module pour tout. Ne pas Votre temps de construction va vite exploser et il vous reste une solution très fracturée. Au lieu de cela, j'ai un module principal, chargé statiquement et contenant tout ce que je veux dans le paquet de base. Tous les addons ou extras deviennent d'autres modules chargés dynamiquement. Il serait peut-être intéressant de décomposer un peu ce module, mais gardez un nombre petit. Cela aide également avec le temps de chargement.

• Je ne suis pas sûr que ce soit une bonne idée, mais j'aime bien garder les interfaces View et ViewModel dans le même fichier que View / ViewModel. J'aime cela parce que le modèle MVVM peut produire beaucoup de fichiers, ce qui permet de réduire le nombre de fichiers. L’inconvénient est qu’Inteface et son implémentation sont plus difficiles à séparer, mais je n’ai probablement pas besoin de le faire, et cette technique n’interfère pas avec les tests, ce qui constitue l’autre avantage.

• Les vues ont tendance à aller dans un dossier Vues, ??puis dans un dossier pour chaque vue. Le dossier de chaque vue comprend la vue, le modèle de vue et le présentateur, le cas échéant.

• A partir de l'implémentation de référence, créez un projet d'infrastructure pour toutes les classes communes devant être partagées entre les modules. L'implémentation de référence contient plus de détails, mais cela peut être utilisé pour toutes sortes de choses, telles que les interfaces de service communes, les constantes, etc.