Comment obtenir un comportement de type héritage avec des types intégrés dans Golang et MongoDB ?

Intégration de types dans Golang et MongoDB : une solution de type héritage

Lors de la conception de modèles de données pour les interfaces utilisateur et les opérations internes, il est courant pour rencontrer la nécessité d'inclure des champs sensibles qui ne devraient être exposés que dans certains contextes. Dans Golang, nous pouvons utiliser le package bson pour gérer la sérialisation des données, y compris l'inclusion ou l'exclusion de champs spécifiques.

Considérez le scénario suivant :

type User struct {
  Id      bson.ObjectId `json:"id,omitempty" bson:"_id,omitempty"`
  Name    string        `json:"name,omitempty" bson:"name,omitempty"`
  Secret  string        `json:"-,omitempty" bson:"secret,omitempty"`
}

Dans cet exemple, le champ Secret est marqué de json : "-" et ne sera pas inclus dans la réponse JSON renvoyée aux utilisateurs généraux. Cependant, pour les utilisateurs administrateurs, nous devons accéder à ce champ. Pour éviter la duplication de code, nous pourrions envisager d'intégrer la structure User dans une structure adminUser, comme ceci :

type adminUser struct {      
  User
  Secret  string        `json:"secret,omitempty" bson:"secret,omitempty"`
}

Malheureusement, cette approche ne fonctionnera pas comme prévu, car seul le champ Secret serait renvoyé, pas les champs Utilisateur.

Pour surmonter ce problème, nous pouvons exploiter l'indicateur bson:",inline" du package bson. Cet indicateur nous permet d'hériter des champs de la structure User intégrée tout en définissant également des champs supplémentaires :

type adminUser struct {
    User `bson:",inline"`
    Secret string `json:"secret,omitempty" bson:"secret,omitempty"`
}

Bien que cela résout le problème d'intégration, cela introduit un nouveau problème : des erreurs de clé en double lors de la lecture des données de la base de données. . Pour résoudre ce problème, il est conseillé de déplacer le champ Secret hors de la structure User vers la structure adminUser. Cela garantit que le champ Secret n'est exposé que dans le contexte adminUser. De cette façon, vous pouvez maintenir un modèle de données cohérent tout en gérant l'exposition des champs sensibles en fonction des rôles des utilisateurs.

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!