Comment organisez-vous vos projets? [fermé]

Avez-vous un style particulier d'organisation de projets?

Par exemple, je suis en train de créer un projet pour quelques écoles ici en Bolivie, voici comment je l'ai organisé:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

Comment organisez-vous exactement votre projet? Avez-vous un exemple de quelque chose que vous avez organisé et dont vous êtes fier? Pouvez-vous partager une capture d'écran du volet Solution?

Dans la zone d'interface utilisateur de mon application, j'ai du mal à choisir un bon schéma pour organiser les différents formulaires et à quel endroit ils appartiennent.

Modifier:

Qu'en est-il de l'organisation de différentes formes dans le projet .UI? Où / comment dois-je regrouper les différentes formes? Les placer tous au niveau racine du projet est une mauvaise idée.

Lors de la conception d'un projet et de la mise en place de l'architecture, je pars de deux directions. Tout d’abord, j’examine le projet en cours d’élaboration et détermine quels problèmes d’affaires doivent être résolus. Je regarde les personnes qui vont l'utiliser et commence par une conception de l'interface utilisateur brute. À ce stade, j'ignore les données et je ne fais que regarder ce que les utilisateurs demandent et qui l'utilisera.

Une fois que j'ai une compréhension de base de ce qu'ils demandent, je détermine quelles sont les données de base qu'ils vont manipuler et commencer une structure de base de données de base pour ces données. Ensuite, je commence à poser des questions pour définir les règles de gestion qui entourent les données.

En partant des deux extrémités de manière indépendante, je suis en mesure de présenter un projet de manière à fusionner les deux extrémités. J'essaie toujours de séparer les dessins aussi longtemps que possible avant de les fusionner, mais gardez à l'esprit les exigences de chacun à mesure que j'avance.

Une fois que j'ai une bonne compréhension de chaque extrémité du problème, je commence à exposer la structure du projet qui sera créé pour résoudre le problème.

Une fois que la présentation de base de la solution de projet est créée, je regarde les fonctionnalités du projet et configure un ensemble de base d'espaces de nom utilisés en fonction du type de travail effectué. Cela peut être des choses comme un compte, un panier d'achat, des sondages, etc.

Voici la présentation de base de la solution par laquelle je commence toujours. À mesure que les projets sont mieux définis, je le peaufine pour répondre aux besoins spécifiques de chaque projet. Certaines zones peuvent être fusionnées avec d'autres et je peux en ajouter quelques unes au besoin.

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

J'aime diviser mes projets en couches

De cette façon, il est plus facile de gérer les dépendances cycliques. Je peux garantir qu'aucun projet n'importe le projet View (couche) par erreur, par exemple. J'ai aussi tendance à casser mes couches en sous-couches. Toutes mes solutions ont donc une liste de projets comme celui-ci:

• Product.Core
• Modèle du produit
• Produit.Présentateur
• Produit.Persistance
• Produit.UI
• Produit.Validation
• Produit.Rapport
• Produit.Web

Ce sont les plus gros "blocs de construction" de mon application. Ensuite, à l'intérieur de chaque projet, j'organise les espaces de noms de manière plus logique, mais cela varie beaucoup. Pour l'interface utilisateur lors de la création de nombreux formulaires, j'essaie de penser à une division spatiale, puis de créer des espaces de noms pour chaque "espace". Supposons qu'il existe un certain nombre de préférences utilisateur contenant des contrôles et des formulaires, j'aurais un espace de noms appelé UserPreferences pour eux, etc.

Organiser des projets

J'essaie généralement de diviser mes projets par un espace de noms, comme vous le dites. Chaque niveau d'une application ou d'un composant correspond à son propre projet. En ce qui concerne la manière dont je décide de diviser ma solution en projets, je me concentre sur la réutilisabilité et les dépendances de ces projets. Je pense à la manière dont les autres membres de mon équipe utiliseront le projet et, si d'autres projets que nous créons ultérieurement, pourraient tirer parti de l'utilisation de certains composants du système.

Par exemple, parfois, il suffit de disposer de ce projet, qui contient tout un ensemble de cadres (courrier électronique, journalisation, etc.):

MyCompany.Frameworks

D'autres fois, je souhaiterai peut-être décomposer les cadres afin qu'ils puissent être importés individuellement:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Organiser des formulaires

L'organisation des formulaires dans le cadre d'un projet d'interface utilisateur se transforme réellement à mesure que votre projet se développe.

• Petit - Un simple dossier Formulaires peut suffire pour un très petit projet. Parfois, vous pouvez créer des structures trop complexes, tout comme vous pouvez créer des espaces de noms et rendre les choses bien plus compliquées qu'elles ne le devraient.

• Moyen à grand - Ici, je commence généralement à diviser mes formulaires en zones fonctionnelles. Si j'ai une partie de mon application qui comporte 3 formulaires pour gérer un utilisateur et d'autres qui gardent une trace des matchs et des scores de football, alors j'aurai un espace Formulaires> Utilisateur et un espace Formulaires> Jeux ou quelque chose comme ça. Cela dépend vraiment du reste du projet, du nombre de formulaires dont je dispose et de la précision de ma décomposition.

N'oubliez pas qu'à la fin de la journée, les espaces de noms et les dossiers ne sont là que pour vous aider à organiser et à trouver les choses plus rapidement.

En réalité, cela dépend de votre équipe, de vos projets et de ce qui est plus facile pour vous. Je suggèrerais qu'en général, vous fassiez des projets séparés pour chaque couche / composant de votre système, mais il y a toujours des exceptions.

Pour des conseils sur l'architecture du système, voir le site Patterns and Practices de Microsoft.

Lorsque j'écris du code dans .NET, il existe une nette tendance à avoir des grappes de fonctionnalités associées. Chacun d'entre eux peut avoir des sous-ensembles identiques. J'aime séparer physiquement les principaux groupes - un par projet par projet. J'ai ensuite subdivisé logiquement en utilisant des assemblages. Suivant ce schéma, l’un de mes projets en cours ressemble à ceci:

• Wadmt (solution)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

J'espère que cela vous sera utile. Les niveaux de séparation m'ont pris du temps à comprendre.

C'est bien d'avoir un plan pour organiser vos solutions, et il y a plusieurs façons de le faire. Certaines fonctionnalités sont partagées entre plusieurs projets, ce qui assure également la cohérence à nos utilisateurs. L'organisation du projet dépend de ce que nous faisons. À la base, nous aurons:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

À partir de là, cela dépend vraiment de la configuration. Si nous avons à la fois une application cliente et une interface Web (utile pour collecter les résultats d'utilisation en classe ou pour d'autres recherches), nous avons besoin d'un projet comportant le code commun partagé (c'est-à-dire les objets de données qui seront sérialisés).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

D'autres sous-projets peuvent être ajoutés si nécessaire. Comme je l'ai dit, cela dépend vraiment du projet. Certains projets sont très simples et ne nécessitent que des éléments de base. Nous essayons de lutter contre la séparation arbitraire des projets, la division par couches a donc tout son sens. Les couches sont définies par ce qui doit être partagé entre les projets, les solutions ou ce qui doit être des plugins / extensions.

Il est intéressant de noter que tant de gens ne considèrent pas DRY ici. Il m'est arrivé à plusieurs reprises dans ma vie de créer des structures de répertoires qu'il n'était pas possible de créer à cause de cela. Gardez le nom du projet hors des répertoires de solutions et de projets!

Alors voici mon chemin:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Lorsque je conçois mon application, je la vois toujours comme des modules séparés par des dépendances . Lorsque j'ai une conception en tête, j'utilise une stratégie ascendante pour la développer. Je développe chaque module, puis je les fais travailler ensemble.

Eh bien, ces modules sont des projets de ma solution (généralement des bibliothèques de classes ). Chaque module a un espace de noms différent et sa propre conception (contenant des classes , etc.).

L' un de ces modules est le GUI ( Graphical User Interface ).

J'utilise également toujours un outil de contrôle de révision pour suivre les modifications apportées à chaque projet. Je suggère Git . C'est opensource, distribué et gratuit à utiliser.

Chaque fois que je commence un nouveau projet, je reçois une description détaillée de ce qu'il est censé faire. Avoir cette contribution m'aide à me fournir un contexte, donc je vais de l'avant et je pense à la méthode la plus appropriée (ou la plus appropriée) pour atteindre les objectifs du projet. À ce stade, je commence à penser que des modèles de dessin peuvent me fournir la solution voulue. Voici où je commence à organiser le projet, en tenant compte des modèles de conception que je vais adopter pour le projet.

Quelques exemples:

1. Si le projet ne concerne que la construction d’écrans de données d’entrée. Très probablement, j'utiliserais un modèle MVC.
2. Si le projet doit être utilisé comme une interface utilisateur très robuste prenant en charge la plupart des plates-formes multiples, un modèle de conception MVVM devient utile.

N'oubliez pas que chacun de ces éléments vous obligera à organiser votre projet de manière spécifique.

Voici quelques lectures pour vous:

Modèles de conception .Net .

Modèles de conception .

Conception orientée objet .

J'espère que cela t'aides.