Structure de projet pour MVVM dans WPF

Question

Quelle est la structure du projet avec laquelle vous vous retrouvez lorsque vous utilisez MVVM dans WPF?

D'après les tutoriels que je viens de voir, ils ont généralement des dossiers: Model, ModelView et View.

Dans Model, vous mettez des classes comme Person, par exemple, qui capturent les données et la logique.

Dans ModelView, vous instanciez les classes définies dans Model. La vue contient des fichiers .xaml.

Modifier: je modifie mon message d'origine pour envoyer un exemple de structure de projet. J'ai une question liée à cela. Comment puis-je organiser ceux-ci: App.config App.xaml MainWindow.xaml

Devrais-je les laisser dehors comme ils sont maintenant ou devrais-je les mettre dans un dossier?

Answer 1

Vous avez décrit la disposition habituelle ou commune des dossiers. Par expérience, je préfère ajouter un dossier séparé (ou un projet dans de grandes applications) pour le type de données de modèle, tel que la classe typique Person que vous avez mentionnée. La raison pour laquelle je le fais est que cela devient souvent l'un des plus gros projets. Je l'ai également divisé dans les sous-dossiers suivants:

DataTypes
    Collections
    Enums
    Interfaces

J'ai également des dossiers distincts (ou des projets dans de grandes applications) pour les classes d'application Converter, de classe d'extension, d'utilitaire (ou de service). Enfin, j'ai des projets de test qui correspondent à peu près à la structure du dossier de l'application. Au total, voici à peu près à quoi mes dossiers ressemblent:

Solution

    Third Party Libraries <<< (Solution Folder)

    StartUp Project
        Images
        Resources

    Converters

    DataTypes
        Collections
        Enums
        Interfaces <<< (For Data Type classes)

    Extensions

    Models
        Data Controllers
        Data Providers
        Interfaces <<< (For swapping Model classes out in test projects)

    Utilities (Or Services)
        Interfaces <<< (For swapping Utilities classes out in test projects)

    View Models
        Commands

    Views
        Attached Properties
        Controls

MISE À JOUR >>>

Les projets, comme les dossiers, fournissent simplement des niveaux de séparation. Ils m'aident également à cartographier les espaces de noms de mes applications. Par exemple, les classes de code dans le dossier/projet Collections seront dans l'espace de noms ApplicationName.DataTypes.Collections. Les classes du dossier/projet Data Providers Auront l'espace de noms ApplicationName.Models.DataProviders.

De plus, dans les grandes applications, les noms de projet proviennent de leur emplacement dans cette hiérarchie ... Par exemple, mon projet DataTypes s'appelle en fait ApplicationName.DataTypes Et mon projet ModelsApplicationName.Models. Les parties Collections et DataProviders sont des dossiers, ainsi que tous les éléments dépassant le deuxième niveau, par exemple. Enums, Images, Commands, etc.

Answer 2

La plupart des gens utilisent la structure "standard" que vous avez mentionnée:

• Modèle/
  • CarModel.cs
  • DriverModel.cs
• ViewModel /
  • CarViewModel.cs
  • DriverViewModel.cs
• Vue/
  • CarView.xaml
  • DriverView.xaml

Je pense que la raison de sa popularité tient au fait que certaines personnes diront que vous devriez pouvoir placer des modèles, des modèles de vues et des vues dans des assemblys différents.

De plus, avec cette structure, vous pouvez facilement ajouter des dossiers pour d’autres contenus WPF: Converters/, Resources/, Etc.

Au sein de mon équipe, nous utilisons cette structure mais nous pluralisons les noms (donc Modèles/ViewModels/Vues).

Cependant, la plupart du temps, les classes de modèle sont définies dans d'autres assemblys/espaces de noms; dans ce cas, nous n'avons même pas de dossier Models/.

Pour les grands projets, nous ajoutons des sous-dossiers dans les champs Models/, ViewModels/ Et Views/

Par souci d’exhaustivité, il convient de mentionner que vous pouvez rencontrer quelques personnes utilisant une structure "pilotée par les fonctionnalités":

• Voiture/
  • CarModel.cs
  • CarViewModel.cs
  • CarView.xaml
• Chauffeur/
  • DriverModel.cs
  • DriverViewModel.cs
  • DriverView.xaml

Mais c'est très rare.

Answer 3

Ce que j’ai d’habitude va comme ceci:

• Application principale (.exe) - Styles globaux, etc.
• Common Lib WPF - Classes de base et aides pour WPF
• Common Lib General - Classes de base et aides pour les modèles
• Infrastructure - Injection de dépendances, journalisation, etc.
• Interfaces pour VM
• Interfaces pour M
• Plusieurs bibliothèques contenant des vues et les modèles de vue correspondants - La division ici est également possible
• Plusieurs bibliothèques contenant des modèles

Toutes les dépendances sont basées sur des interfaces uniquement résolues via DI.

Answer 4

Mes amis, la solution que j'ai trouvée pour un problème similaire à celui-ci consistait à créer un projet distinct, de type WPF, que j'ai appelé Startup, uniquement avec App.xaml (et App.xaml.cs).

Dans ce document, je me réfère au projet de View et ViewModel. Ainsi, la vue n'a pas de dépendance et ViewModel "voit" uniquement la vue et l'entreprise.

Dans App.xaml.cs, déclarez et instanciez mon MainWindow, puis chargez quelques propriétés de base de mon application et accédez à la page de connexion (je travaille avec une fenêtre et plusieurs pages qui y sont parcourues).