Maison >développement back-end >Golang >Comment éviter de rendre les dépendances disponibles à tous les packages d'un module ?

Comment éviter de rendre les dépendances disponibles à tous les packages d'un module ?

王林
王林avant
2024-02-05 23:57:071093parcourir

Comment éviter de rendre les dépendances disponibles à tous les packages dun module ?

Contenu de la question

Issu d'un milieu .net, j'essaie actuellement d'adapter mon premier projet go à une structure de projet go plus typique (similaire à celle-ci). Ce que je ne comprends pas, c'est comment éviter que des dépendances ne se retrouvent accidentellement dans des packages auxquels elles n'appartiennent pas.

Supposons que j'ai un projet composé de deux parties, une application nommée foo et un modèle.

  • Mon modèle n'a presque aucune dépendance
  • foo Les applications peuvent dépendre des bibliothèques http, de journalisation, de métriques, etc.

Le projet pourrait ressembler à ceci :

├── go.mod
├── go.sum
├── model
│   ├── person.go
│   └── address.go
├── cmd
│   └── runfoo
│       └── main.go
└── foolib
    └── applicationlogic.go

Mais comme les fichiers du module se trouvent dans le répertoire racine, go get github.com/httplib 将使 httplib est également disponible pour ce modèle. Cette méthode présente des inconvénients :

  • C'est si simple (surtout avec des fonctionnalités comme l'importation automatique de vscode) qu'il est parfois facile d'exiger httplib dans un modèle même si cela n'y appartient certainement pas.
  • En regardant go.mod, je n'arrive pas à comprendre quelles dépendances sont pour le modèle et lesquelles sont pour l'application.

Maintenant, je peux utiliser des modules très fins et ajouter des fichiers go.work pour le développement, mais cela semble difficile à maintenir (et ne correspond pas à la structure de référence).

Comment éviter de rendre les dépendances disponibles à tous les packages ? Est-ce sage ?


Bonne réponse


Comment éviter de rendre les dépendances disponibles à tous les packages[? ]

Vous ne pouvez pas (utiliser un module).

[…] Est-ce sage ?

Non, absolument pas.

Les "inconvénients" que vous voyez ne posent aucun problème et ne poseront aucun problème dans la pratique.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer