0
Imaginons que vous créez un système dorsal complexe. Quelque part dans le système, vous avez une interface IQueue. Vous prévoyez d'avoir plusieurs implémentations pour la file d'attente:Organisation de la solution/des projets Visual Studio
- Naive « en mémoire »
- Database (où la file d'attente est gérée dans une base de données)
- Amazon SQS (en utilisant du service Amazon SQS dans le nuage)
- MS/Google/Autres services File d'attente
de toute évidence, chaque mise en œuvre exigera sa propre classe et la mise en œuvre. Chaque mise en œuvre aura probablement besoin de références différentes (base de données nécessite les DLL pour communiquer avec la base de données pertinentes, Amazon SQS exigera DLLs Amazon AWS, etc.)
Comment voulez-vous organiser la solution pour un tel scénario?
En supposant que l'interface et la mise en œuvre naïve sont des lieux dans le projet où la file d'attente est utilisé, je vois les options possibles suivantes:
- Visual Studio séparé (et donc l'assemblage) pour chaque mise en œuvre:
- Pro: des projets propres, la « responsabilité unique » au niveau du projet, plus facile à mettre à jour la mise en œuvre spécifique
- Con: de nombreux projets, de nombreuses assemblées pour gérer/deploy, Visual studio plus lent
- Projet unique pour toutes les implémentations "non-naïves":
- Pro/Con: exact opposé de la première option.
Définitivement plus d'assemblages. – TcKs
La façon dont vous avez exposé les avantages/inconvénients n'a aucun sens. Créez plusieurs projets dans une solution unique problème résolu. Tout est propre, facile à mettre à jour, vous ne violez pas la responsabilité unique, etc. etc. Si Visual Studio devient trop lent, faites un clic droit sur les projets que vous ne travaillez pas dans l'Explorateur de solutions et sélectionnez "Décharger le projet". C'est précisément à cela que les solutions ont été conçues *. –
@Cody: Je suis bien conscient que les projets sont conçus pour cela. Cependant, juste "pop-up" de plus en plus de projets, sans y penser, est une mauvaise pratique. Et vous ne pouvez pas vous éloigner du fait que plus de projets entraîne un VS plus lent (et que le déchargement des projets n'est pas vraiment une solution), et un temps de construction plus lent. Et ajoutez à cela le fait que vous devez gérer/déployer/etc chaque assemblage que vous ajoutez ... – SaguiItay