Par exemple, j'ai un projet Common.Utils.csproj et l'utilise dans tous les autres projets. Je peux stocker ses sours (Utils) dans un dépôt, le modifier seulement ici, m'enregistrer dll dans gac et l'utiliser comme dll dans d'autres projets, ou je peux cloner sourse partout où j'ai besoin, inclure projet dans solution, l'utiliser comme source et pousser modifications. Alors, quelle est la meilleure pratique?Comment fonctionne le projet d'utilitaires communs
Je recommanderais de l'avoir dans un seul endroit et que vos autres projets référencent cela, de sorte que tous les changements seront disponibles, sans avoir à mettre à jour toutes les copies. Le seul problème que vous pourriez rencontrer est si vous changez la signification de manière significative, ce qui pourrait casser la rétrocompatibilité, mais vous devriez essayer de coder pour cela. Mais cela ne devrait pas être un problème majeur si vous utilisez des cas de test pour vos méthodes courantes, pour vous assurer que les méthodes précédemment utilisées fonctionnent toujours correctement.
Évitez les bibliothèques util à tout prix. Ils sont une odeur de code qui indique la violation de beaucoup de principes SOLIDES; en premier lieu le Single Responsibility Principle.
Ayende l'explique très bien here. Que dois-je faire avec ce cours?
StringExtensions public static class { public static bool IsEmpty (cette chaîne str) public static string Supprimer (cette chaîne str, valeur de chaîne) } – dotneter
Je ne dis pas que vous ne pouvez pas faire des bibliothèques du tout, mais plutôt vous devriez être très méfiant des bibliothèques utilitaires communes. Si vous devez avoir une classe comme StringExtensions, il est toujours préférable de la placer dans une bibliothèque ciblée qui ne traite que des chaînes. Cependant, une telle bibliothèque soulève encore la question de savoir si elle fournit vraiment plus de valeur que le coût associé à son maintien. J'ai tendance à penser que non. –