J'ai un projet appelé Data qui est une couche de données. Dans ce projet, tous les fichiers ne sont que situés dans le dossier supérieur. J'ai des énumérations, des pocos, des référentiels, des classes partielles et ainsi de suite.
Si je veux déplacer ces fichiers en sous-dossiers, quel serait le nom de dossier préféré pour chaque dossier? Y a-t-il une convention?
Le dossier "référentiels" est assez évident, mais où dois-je garder les pocos et les énumérations?
merci
5 Réponses :
J'ai tendance à utiliser des dossiers de projet comme moyen de séparer les espaces de sous-noms. Donc, dans votre cas, un dossier appelé des référentiels, qui a une classe dans l'espace de noms Data.RePositories. Remarque, pour les classes partielles, chaque fichier doit être dans la même espace de noms.
La meilleure pratique consiste à diviser les entités des dossiers par type de modèle d'objet, pas par type.
Une bonne pratique consiste à nommer le dossier après le nom du projet.
Directives de conception pour le développement de bibliothèques de classe a un ensemble de Lignes directrices pour les noms
Le dernier article devrait être d'intérêt périmé pour vous:
S'il n'est pas clair comment regrouper les classes par utilisation ou modèle d'objet signification, laissez-les tout simplement dans un dossier. L'utilisation de sous-dossiers ne donne pas de valeurs s'ils n'organisent pas les classes de manière significative.
Dossiers de division par type, par exemple Les énumérations, les pocos, les référentiels, les classes partielles, etc. ne sont pas susceptibles d'être utiles.
Vous pouvez utiliser un sous-dossier pour le code généré qui ne doit pas être édité.
N'oubliez pas également que vous pouvez avoir des dossiers dans l'explorateur de solution qui ne font pas partie du système de fichiers. Étant donné à quel point il est coûteux (à temps) dans certains systèmes de contrôle de code source pour déplacer des fichiers entre les répertoires, je envisagerais de commencer simplement à utiliser MSDev Dossiers jusqu'à ce que vous soyez clair sur la structure souhaitée.
Il n'y a pas besoin pour mettre chaque énumération dans son propre fichier, si une énumération est uniquement
i (actuellement - modifications basées sur le projet) tendent à utiliser cette approche lors de la nommage des assemblages / projets / espaces de noms dans un projet SaaS / Web Style)
Pour expliquer le client Services / Service ... J'utilise un CIO (actuellement Structuremap) qui permet à mon webclient de parler directement à la couche d'entreprise ou d'être redirigé pour parler de la serviceclient via des services à la couche d'entreprise. Cela me donne la flexibilité de déployer mon calque d'applications à mes applications Web ou de distribuer des morceaux de ma couche d'entreprise (couche d'application) à différents serveurs à titre de principes de WCF / SOA.
Bien que cela ne soit pas directement lié à votre question, vous devriez probablement envisager de renommer votre projet à quelque chose de plus significatif et conforme aux directives de conception-cadre. Maintenant, sur votre question: FDG donne également des conseils sur quand et comment structurer les espaces de messagerie. Stackoverflow.com/Questtions/1389458/...