Comment organisez-vous vos projets?
Avez-vous un style particulier d'organisation de projets?
Par exemple, actuellement je crée 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 ma demande, j'ai du mal à décider d'un bon schéma pour organiser les différents formulaires et leur place.
Modifier:
Qu'en est-il de l'organisation de différentes formes dans le projet .UI? Où/comment dois-je grouper des formulaires différents? Les mettre 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. Je regarde d'abord le projet en cours de conception et je détermine quels problèmes commerciaux doivent être résolus. Je regarde les gens qui vont l'utiliser et je commence par une conception d'interface utilisateur grossière. À ce stade, j'ignore les données et je regarde simplement ce que les utilisateurs demandent et qui va les utiliser.
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 commence une disposition de base de données pour ces données. Ensuite, je commence à poser des questions pour définir les règles métier qui entourent les données.
En partant des deux extrémités indépendamment, je suis en mesure de présenter un projet de manière à fusionner les deux extrémités. J'essaie toujours de garder les dessins séparés aussi longtemps que possible avant de les fusionner, mais gardez à l'esprit les exigences de chacun au fur et à mesure que j'avance.
Une fois que j'ai une bonne compréhension solide 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 la configuration de base de la solution de projet créée, j'examine les fonctionnalités du projet et configure un ensemble de base d'espaces de noms qui sont utilisés en fonction du type de travail effectué. Cela peut être des choses comme le compte, le panier, les enquêtes, etc.
Voici la disposition de base de la solution avec laquelle je commence toujours. Au fur et à mesure que les projets sont mieux définis, je les affine 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'importera le projet View (calque) par erreur, par exemple. J'ai également tendance à casser mes couches en sous-couches. Donc, toutes mes solutions ont une liste de projets comme celui-ci:
- Produit.Core
- Modèle du produit
- Product.Presenter
- Produit.Persistance
- Product.UI
- Produit.Validation
- Produit.Rapport
- Product.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 d'un grand nombre de formulaires, j'essaie de penser dans une division spatiale, puis de créer des espaces de noms pour chaque "espace". Disons qu'il y a un tas de contrôles utilisateur et de formulaires utilisateurs, j'aurais un espace de noms appelé UserPreferences pour eux, et ainsi de suite.
Organisation de projets
J'essaie généralement de diviser mes projets par espace de noms, comme vous dites. Chaque niveau d'une application ou d'un composant est son propre projet. En ce qui concerne la façon dont je décide comment diviser ma solution en projets, je me concentre sur réutilisabilité et dépendances de ces projets. Je pense à la façon dont les autres membres de mon équipe utiliseront le projet, et si d'autres projets que nous créons en cours de route pourraient bénéficier de l'utilisation de certains composants du système.
Par exemple, parfois, le simple fait d'avoir ce projet, qui a un ensemble complet de frameworks (email, logging, etc.) est suffisant:
MyCompany.Frameworks
D'autres fois, je souhaiterai peut-être diviser les cadres en morceaux, afin qu'ils puissent être importés individuellement:
MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework
Organisation des formulaires
L'organisation des formulaires dans un projet d'interface utilisateur se transformera vraiment à mesure que votre projet se développe.
Petit - Un simple dossier Forms pourrait suffire pour un très petit projet. Parfois, vous pouvez surcharger les structures comme vous le pouvez pour les espaces de noms et rendre les choses beaucoup plus compliquées qu'elles ne devraient l'être.
Moyen à grand - Ici, je commence généralement à diviser mes formulaires en domaines fonctionnels. Si j'ai une partie de mon application qui a 3 formulaires pour gérer un utilisateur et certaines qui gardent une trace des matchs de football et des scores, alors j'aurai une zone Formulaires> Utilisateur et a = Forms> Games zone ou quelque chose comme ça. Cela dépend vraiment du reste du projet, du nombre de formulaires dont je dispose quant à la finesse de la décomposition.
N'oubliez pas qu'à la fin de la journée, les espaces de noms et les dossiers sont là pour vous aider à organiser et à trouver les choses plus rapidement.
Vraiment, cela dépend de votre équipe, de vos projets et de ce qui est plus facile pour vous. Je dirais qu'en général, vous faites 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 site Patterns and Practices de Microsoft.
Lorsque j'écris du code dans .NET, il y a une nette tendance à avoir des grappes de fonctionnalités connexes. Chacun d'eux peut avoir des sous-ensembles identiques. J'aime séparer physiquement les principaux groupes - l'un d'eux par projet VS. Je subdivise ensuite logiquement en utilisant des assemblages. Suivant ce schéma, 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 un certain temps pour comprendre.
C'est bien d'avoir un plan pour organiser vos solutions, et il y a plusieurs façons de le faire. Nous avons certaines fonctionnalités qui sont partagées entre plusieurs projets, ce qui assure également la cohérence pour nos utilisateurs. L'organisation du projet dépend de ce que nous faisons. À sa 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 dans d'autres recherches), nous avons besoin d'un projet qui a le code communement 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 vraiment simples et ne nécessitent que des éléments de base. Nous essayons de lutter contre la séparation arbitraire des projets, donc division par couches est vraiment logique. 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 est arrivé plusieurs fois dans ma vie que les développeurs ont créé des structures de répertoires qui n'ont pas pu être construites à cause de cela. Conservez le nom du projet des répertoires de solutions et de projets!
Voici donc ma voie:
{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 modules avec quelques dépendances entre eux. Quand j'ai une conception en tête, j'utilise une stratégie de bas en haut pour la développer. Je développe chaque module et puis je les fais travailler ensemble.
Eh bien, ces modules sont projets sous ma solution (généralement bibliothèques de classes). Chaque module a un espace de noms différent et sa propre conception (contenant classes, etc.).
L'un de ces modules est le [~ # ~] gui [~ # ~] ( graphique Interface utilisateur).
J'utilise également toujours un outil Revision Control pour suivre les changements dans chaque projet. Je suggère Git . Il est open source, distribué et gratuit.
Chaque fois que je commence un nouveau projet, j'obtiens une large spécification de ce qu'il est censé faire. Avoir cette contribution m'aide en me fournissant un contexte, donc je vais de l'avant et je pense à la meilleure méthode (ou la plus appropriée) pour atteindre les objectifs du projet. À ce stade, je commence à penser dans quels modèles de conception peuvent m'aider à fournir la solution prévue. C'est ici que je commence à organiser le projet, en tenant compte des modèles de conception que j'adopterai pour le projet.
Quelques exemples:
- Si le projet ne concerne que la création d'écrans de données d'entrée. J'utiliserais très probablement un modèle MVC.
- Si le projet doit être utilisé comme une interface utilisateur robuste qui prend en charge la plupart des plates-formes multiples, un modèle de conception MVVM devient utile.
Gardez à l'esprit que chacun de ces éléments vous obligera à organiser votre projet d'une manière spécifique.
Voici quelques lectures pour vous:
. Motifs de conception nette .
J'espère que cela t'aides.