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.