Les bibliothèques de classes .NET Core doivent-elles enregistrer leurs propres implémentations?
Notre équipe a récemment eu beaucoup de mal à décider si c'est une bonne pratique pour les bibliothèques de classes .NET Core d'enregistrer leurs propres implémentations du fait de fournir une méthode d'extension IServiceCollection comme AddMyServices ().
Mon point était qu'il est bon de le faire parce que:
- L'application de niveau supérieur n'a pas besoin de connaître tous les détails de la bibliothèque sous-jacente qu'elle va utiliser,
- L'application de niveau supérieur (généralement la classe de démarrage) n'est pas polluée par des références à tous les espaces de noms requis pour enregistrer son implémentation.
- Si une application de niveau supérieur souhaite fournir sa propre implémentation personnalisée de certaines interfaces définies dans la bibliothèque référencée, elle peut toujours le faire. L'injection de dépendances .NET Core permet plusieurs enregistrements.
- S'il y a plus d'applications référençant cette bibliothèque de classes, vous n'auriez pas besoin de copier-coller un bloc de par ex. Ajoutez des lignes transitoires à chaque application.
Les contre-arguments étaient les suivants:
- Certains exemples d'applications utilisent l'approche consistant à enregistrer toutes les implémentations dans la méthode de démarrage de niveau supérieur.
- L'approche ci-dessus n'est utilisée que pour les fonctionnalités (mais elle crée des doutes sémantiques sur ce qui peut être appelé une fonctionnalité et ce qui ne l'est pas). La bibliothèque de classes Still peut nommer les fonctionnalités qu'elle implémente et fournir des méthodes AddFeatureXYZ () distinctes dans la classe d'extension IServiceCollection.
- L'utilisation de la méthode d'extension AddService () qui enregistre toutes les implémentations qu'il peut fournir, peut avoir un impact sur les performances du conteneur DI, ce qui est logique dans le cas où certaines bibliothèques de classes fournissent de nombreuses implémentations mais que peu sont utilisées. Mais un développeur a toujours la liberté d'appeler AddServices () ou non.
Je voulais poser des questions aux développeurs .NET Core plus expérimentés sur leurs approches avec tous les pros, ce qui me manque peut-être. S'il y a des arguments solides pour utiliser la deuxième approche que je n'ai pas énumérée ici, j'aimerais vraiment en prendre connaissance.
PS. Cette question a été déplacée de StackOverflow car elle a été marquée comme davantage basée sur l'opinion. À mon avis, cela touche les principes fondamentaux de la programmation orientée objet, et la question n'est pas de savoir quelle majorité de développeurs choisit, mais de savoir pourquoi quelqu'un privilégie une approche par rapport à l'autre.
Merci, Radek
Les principaux documents ASP.Net le recommandent
Chaque service. Ajouter la méthode d'extension {SERVICE_NAME} ajoute (et configure éventuellement) des services. Par exemple, services.AddMvc () ajoute les services dont Razor Pages et MVC ont besoin. Nous avons recommandé que les applications suivent cette convention. Placez les méthodes d'extension dans l'espace de noms Microsoft.Extensions.DependencyInjection pour encapsuler des groupes d'inscriptions de service.
Mais non.
L'une des choses les plus ennuyeuses à propos de la configuration des plugins est d'essayer de deviner la méthode d'extension à utiliser pour les configurer. Ou je devrais dire, la version que vous en avez car le nom semble changer entre les versions et les frameworks
Deuxièmement, souvent ces méthodes d'enregistrement cumulées n'exposent pas toutes les choses que vous pourriez vouloir remplacer ou configurer sur les services sous-jacents. L'intérêt du gestionnaire de services est que vous puissiez remplacer les dépendances lorsque cela est nécessaire, mais la méthode d'extension qui le fait pour vous peut empêcher cela.
Mais peut-être plus important encore, je ne pense pas que cette convention ait encore pris racine. Il semble y avoir des philosophies concurrentes en ce qui concerne startup.cs et program.cs. Si vous ne soutenez qu'une seule méthode, vous allez être du mauvais côté de quelqu'un.
Je fournirais la méthode d'extension, mais dans un package optionnel séparé. Autorisez les utilisateurs à enregistrer manuellement les composants s'ils le souhaitent ou utilisez la méthode d'extension pour une configuration par défaut.