Je me demandais ici, comment organisez-vous vos projets, en termes de fonctionnalité, de portée, etc.
Avez-vous un projet pour des tests d'unités, un projet pour le code de la bibliothèque de classe, un projet d'interface utilisateur?
ou vous divisez-vous simplement tous ces dans des dossiers séparés?
Je pensais que la séparation de ceux-ci par des projets est plus facile, car votre bibliothèque de code centrale est à un endroit, sans références directes à l'userface (aucune dépendances WinForms) ou les plusestes.
Toute opinion?
8 Réponses :
Faites des recherches sur la pile débordement et sur Google - il y en a d'autres qui ont posé la même question.
Quelques considérations:
Visual Studio prend plus de temps à compiler des solutions avec de nombreux projets que de grands projets. Ne divisez pas votre solution trop finement.
's Guide de l'application composite a un moyen intéressant de diviser projets. Il existe un projet d'infrastructure, un projet BootsTrapper, puis des projets pour chaque "module" du code.
Actuellement, je travaille sur un projet qui divise les projets comme votre exemple: infrastructure, logique commerciale, interface graphique et tests d'unité.
Je préfère organiser des fichiers à des fins, pas de type. Par exemple, je crée des dossiers appelés "communication" et "interop" plutôt que "événements" et "interfaces".
Avez-vous un projet pour l'unité Tests, un projet pour la bibliothèque de classe code, un projet d'interface utilisateur?
À peu près ceci. Gardez généralement l'interface utilisateur maigre et déplacez toute la logique d'entreprise dans son (s) projet (s), avec un projet de test par projet de logique d'entreprise.
Je brise des projets par type d'assemblage comme vous l'avez décrit. Il est bon d'avoir au moins le projet principal qui est exécutable (s'il s'agit d'une application) et d'une ou plusieurs bibliothèques de classe. S'il s'agit d'une application Windows, essayez définitivement de séparer l'interface utilisateur du code autant que possible. Les applications WPF font un travail merveilleux d'accomplir cela.
Autre que cela, certains autres conseils que je pourrais prêter sont définitivement collecter des bibliothèques de classe tiers et écrire une partie de votre choix lorsque la réutilisation du code est évidente ou apparente.
J'essaie de diviser des projets en ce que vous pourriez appeler "unités de déploiement". En d'autres termes, "Comment puis-je déployer ces assemblées?"
Parce que je ne déplouvais évidemment pas de tests unitaires, ils sont dans leur propre projet.
Je divisez ensuite l'interface utilisateur et la "logique des affaires" dans des projets distincts. Si je garde ces lignes de séparation propre, je peux remplacer ma couche d'interface utilisateur avec une nouvelle technologie ou une nouvelle infrastructure (pensez WPF vs.net) et réutilisez toujours les assemblages "logiques" pour les deux. Je viens d'introduire une nouvelle couche d'interface utilisateur qui comprend l'interface logique commerciale.
J'essaie également de conserver une bibliothèque distincte pour le code que je pourrais partager entre des solutions. Ce serait mes utilitaires d'accès aux données, des services d'analyse de dossiers et d'autres que j'utilise encore et plus que je construis des projets. Je peux simplement inclure ces assemblées dans mes nouvelles solutions et je reçois toutes ces fonctionnalités que j'ai déjà investi mon temps.
espère que cela aide.
Les quelques derniers projets à laquelle j'ai participé - nous avons fini par la structure suivante (tous les projets Prism WPF):
xxx.shell.exe
xxx.yyyymodule.dll (x 4-7)
xxx.Test
xxx.model
xxx.common
et pour ceux qui utilisent WCF - Ajouter:
xxx.backend
xxx.datacontractes
Tout dans une solution dans une seule (nous vivons avec les longueurs de butées ...) la divisant en solutions séparées introduites trop de problèmes lors du refactoring. Jusqu'à présent, cela a bien fonctionné pour nous.
Quelques modèles que j'ai trouvés utiles dans l'organisation de projets dans une solution:
J'ai presque toujours un projet "commun" ou "utils". Ce projet devrait avoir très peu de dépendances. Il peut donc être facilement réutilisé n'importe où et partout dans ma solution (ou éventuellement dans d'autres solutions). Vous serez surpris de savoir combien de petites classes d'assistance tomberont dans ce projet.
J'essaie toujours de séparer ma logique d'entreprise en un projet (ou plus probablement un ensemble de projets) et mon code bootstrap / fournisseur dans un projet différent (ou ensemble de projets). Mes classes de bootstrap / fournisseur sont spécifiques au contexte (elles peuvent assumer la présence d'un point httpcontext ou de la ligne de commande arguments, etc.), mais ils ne contiennent aucune logique commerciale. Mes cours d'entreprise mettent en œuvre la logique commerciale, mais n'assument pas la présence ou l'absence d'éléments spécifiques au contexte. De cette façon, si je construise initialement le système en tant qu'application de console, je peux plus tard écrire un ensemble de bootstrap / fournisseurs de service Windows-Service, et de le transformer très rapidement en un service Windows avec un impact minimal et sans aucun impact sur les classes de l'entreprise. < / p>
Semblable aux classes de bootstrap / fournisseur, j'essaie également d'isoler ma couche de données de mes classes d'entreprise. Mais c'est une séparation fondamentale commune que tout le monde a entendu 1000 fois, il est donc presque mérite d'être mentionné.
La logique commerciale de nombreux systèmes est trop complexe pour s'intégrer à un seul projet et conserver un degré de maintenabilité du code. Ainsi, je me trouve habituellement avec plusieurs projets logiques commerciaux, regroupés par zone fonctionnelle («mangement client», «inventaire des produits», etc.).
J'ai aussi un dossier Utils, pas un projet. J'ai dans les diagrammes de classe, les classes réutilisables, etc. Bon conseil!
Je vais quelque chose comme ça en termes de projets dans une solution:
Administration - Documentation générale, copie principale de la licence, etc. Je ferai également cette compilation à une application de "Readme" de la ligne de commande qui affiche la licence, les notes de révision, etc.
données - données générales, telles que XML, etc. Aucun code compilable.
bibliothèque1 ... Bibliothèque - une ou plusieurs bibliothèques (généralement 1-3: utils, noyau, code étendu).
Application1 ... ApplicationN - Application (généralement une).
test1 ... TESTN - TESTS.
Au sein de chaque projet, je conserve les fichiers de chaque espace de noms dans des dossiers distincts, des espaces de sous-noms dans les sous-dossiers, etc. Je garde des types de choses courants, tels que la documentation, les données de la bibliothèque ou des données spécifiques à une application, du texte de licence intégré, etc. ., dans les sous-dossiers avec le même nom quel que soit le projet.
-NEIL
Si vous faites une application business-ish avec une interface utilisateur, vous devriez examiner Bien sûr, MVC n'est qu'un concept général, mais c'est celui qui vous aide à prendre des décisions du genre que vous êtes confrontés en ce moment.
Il y a beaucoup de ressources sur MVC dans WPF , que vous pouvez probablement Appliquer directement sur Winforms aussi.