Structure de projet WPF recommandée?

Je suis un stickler pour les bonnes structures Visual Studio Solution et Project.Structure de projet WPF recommandée?

Je suis sur le point de lancer un travail de preuve de concept WPF.

Quelqu'un peut-il recommander certaines structures de projet WPF qu'ils ont utilisées et qui ont bien fonctionné?

Ici http://drwpf.com/blog/2007/10/01/58/

Ils ont une recommandation que j'aime:

Root 
    - Pages 
    - Controls 
    - Resources 
    App.xaml

Où Pages, contrôles et ressources sont des dossiers.

Est-ce que quelqu'un a trouvé que certaines structures fonctionnent bien/ne fonctionnent pas bien?

Aussi je préfère ne pas entrer dans une discussion 'Model View Presenter' si cela vous convient.

Source

2010-08-06 Lee Englestone

Sérieusement, pourquoi avez-vous besoin d'une validation sur quelque chose comme ça? Vous pouvez faire glisser/déposer des trucs plus tard si vous en avez besoin, et le support de refactoring dans VS (surtout 2010) est plutôt bon. – slugster

Vous ne prenez pas le temps de planifier les choses avant de commencer? Si vous ne parvenez pas à vous préparer, préparez-vous à l'échec. Bien sûr, vous pouvez changer les choses plus tard, mais ce n'est pas vraiment un bon argument pour ne pas prendre le temps au début et la planification est-elle? –

Mon point est: l'exemple que vous avez donné est bien, pourquoi avez-vous besoin de personnes pour le critiquer? Planifiez à l'avance, mais n'oubliez pas qu'au début d'un projet, les choses seront quelque peu fluides et vous changerez d'emplacement et d'espace de noms. Catégoriser les choses d'une manière qui a du sens pour ** vous ** et votre équipe. Après une semaine ou deux, vous trouverez des choses qui s'installent et vous ne bougerez plus autant, voire pas du tout. Organiser un * projet * n'est pas une grosse affaire - organiser une * solution * à l'avance a un retour sur investissement plus important pour votre temps de planification. – slugster

J'ai tendance à avoir les répertoires suivants: Convertisseurs, Modèles, Ressources, ViewModels et Vues.

J'ai aussi vu une solution où la vue et ViewModels ont été divisé en plusieurs projets distincts (voir BubbleBurst sur CodePlex)

Source

2010-08-06 11:40:59 alimbada

Merci d'avoir lancé la balle alimbada –

Je suis d'accord avec alimbada. Nous avons également créé différents projets pour les modèles View et View. Cela rend les choses plus faciles à maintenir en cas d'énormes projets. Annuaires que nous avions étaient -

- ViewsRoot 
    + Base 
    + Controls 
    + Documentation 
    + Forms(Windows) 
    + Reports 
    + Resources 
    + Themes 
    + Utilities 
    App.xaml 

- ViewModelsRoot 
    + Collection 
    + Commands 
    + Converters 
    + Resources 
    + TemplateSelectors 
    + ViewModels 
    + Views (Interfaces for views) 
    Constants.cs 
    Utility.cs

Je crois aussi dans la planification de la structure à l'avance, cela rend facile pour tous les développeurs à s'y habituer et suivre la même chose. Faire cela plus tard ajoute de la confusion et est douloureux dans le cas où vous devez créer des projets séparés. C'est mon point de vue et je suis ouvert à connaître d'autres meilleures approches pour cela.

Source

2010-08-06 12:42:09 akjoshi

J'aime ça. Où placeriez-vous Propriétés/Comportement Attached dans ce schéma? Je casse cela dans un dossier séparé que j'appelle Behavior. – Berryl

J'ai également un projet 'core' d'éléments wpf qui ont tendance à être réutilisables sur plusieurs projets.Des choses comme les constantes, les utilitaires, les contrôles et les comportements (qui ont probablement des homologues spécifiques au projet) – Berryl

J'ai été tenté de changer le nom de Ressources en Actifs, uniquement parce que la ressource est un concept si chargé, surtout si vous avez besoin de localisation. Cheers – Berryl

Répondre

Questions connexes