Un objet doit-il connaître son propre ID?

obj.idsemble assez commun et semble également se situer dans la portée de quelque chose qu'un objet pourrait savoir sur lui-même. Je me demande pourquoi mon objet devrait-il connaître son propre identifiant?

Il ne semble pas avoir de raison de l'avoir? L'une des principales raisons de son existence est de le récupérer, et donc mes référentiels doivent le connaître, et donc l'utiliser pour l'interaction de la base de données.

J'ai également rencontré un problème où je voulais sérialiser un objet en JSON pour une API RESTful où l'ID ne semblait pas tenir dans la charge utile, mais seulement l'URI et l'inclure dans l'objet rendait cela plus difficile.

Un objet doit-il savoir son propre identifiant? pourquoi ou pourquoi pas?

mise à jour : Termes

1. id: attribut identifiant sur un objet. en termes de base de données, une clé de substitution n'est pas une clé naturelle.
2. Objet: une entité, ou autre objet identifiable de manière unique au sein du système.

Réponse courte: l' inclusion d'un identifiant d'objet dans l'objet est indispensable s'il doit être référé.

Pour un scénario dans lequel vous prévoyez d'utiliser une collection d'objets et prévoyez de référencer un objet / entité individuel, l'identifiant doit être inclus. Cependant, il peut y avoir des cas où une clé / un identificateur naturel comme DateTimepeut répondre artificiellement à ce besoin.

De plus, vous pouvez avoir votre DTO en tant que conteneur léger de votre objet, qui peut ignorer / inclure l'identifiant d'objet en soi. Vraiment, tous ces choix dépendent vraiment des cas d'utilisation et des besoins de votre entreprise .

Modifier: si vous voulez identifier votre objet, vous devez avoir un identifiant. Cet identifiant peut être un identifiant de substitution, une date-heure, un guid, etc ... fondamentalement, tout ce qui identifie votre objet des autres de manière unique.

Afin de laisser ma réponse aussi abstraite que votre question, je pense que vous avez en fait répondu à votre propre question.

Un objet doit connaître son propre ID s'il en a besoin.

Un objet ne devrait pas connaître son ID (ou qu'il en a même un) s'il n'en a pas besoin.

Comme vous l'avez souligné, il existe des cas où il est gênant ou inutile que l'objet conserve ou sache si son ID. Mais il existe d'autres cas où il est plus pratique pour l'objet de connaître son ID. Codez vos objets en fonction de leur utilisation.

Il est assez courant d'inclure l'ID, mais il est également courant d'utiliser des dictionnaires, c'est-à-dire les structures de données où chaque objet est associé à son ID de manière à ce que vous puissiez facilement récupérer cet objet en connaissant l'ID correspondant, mais l'objet ne sait pas il.

Par exemple, si vous créez une API avec deux méthodes:

• http://api.example.com/products/

  Charge la liste des ID de produits.

• http://api.example.com/product/452/

  Charge un produit de l'ID 452.

Ensuite, vous n'avez pas besoin de renvoyer l'ID 452 dans la réponse JSON de la deuxième demande. L'utilisateur de l'API connaît déjà l'ID.

Je pense que cela est subjectif et dépend de votre conception.

Surtout si cela semble être une conception qui provient d'un enregistrement actif . Dans un enregistrement actif, votre entité dispose de méthodes pour effectuer des opérations de base de données et doit donc également connaître son identifiant de base de données.

Lorsque vous utilisez d'autres modèles tels qu'un référentiel avec un mappeur de données stockant ces données dans l'objet, cela devient inutile et peut-être inapproprié.

Prenons par exemple un Personobjet. On me donne un nom qui peut ou non être unique au sein d'une famille. Comme la population a grandi, les noms plus grands ne sont plus uniques et nous avons donc trouvé des identifiants de substitution pour un système de plus en plus grand. Par exemple: mon permis de conduire et mon numéro de sécurité sociale. Je ne suis pas né avec un identifiant, tous ces identifiants doivent être demandés.

La plupart d'entre eux ne font pas de bonnes clés primaires / identifiants pour les logiciels, car ils ne sont pas universels. Du moins pas en dehors de leur système spécifique, il est évident qu'un SSN est unique et cohérent avec la Social Security Administration. Puisque nous ne sommes généralement pas les fournisseurs de ces informations, vous ne les appelleriez pas idmais plutôt les données qu'ils représentent, par exemple SSN. Parfois, même contenir l'objet composé complet comme un DriversLicensequi pourrait contenir toutes les informations du permis de conduire.

Tous les identifiants généraux sont donc des clés de substitution dans le système et pourraient être remplacés par des références en mémoire, ne contenant que des identifiants pour faciliter la recherche et la persistance d'enregistrements.

Puisqu'une idn'est pas une donnée conceptuelle, je doute qu'elle fasse (généralement) partie de l'objet, car elle ne vient pas du domaine. Il devrait plutôt être conservé dans son but qui est d'identifier un objet qui n'a pas d'autre moyen de représenter une identité unique. Cela pourrait être fait dans un référentiel / collection avec easy.

Dans le logiciel, si vous devez représenter l'objet sous forme de liste, ou le conserver, vous pouvez simplement le faire à partir de l'objet de référentiel / collection, ou d'un autre objet associé à cela. Lorsque vous passez au Data Mapper (s'il est séparé), vous pouvez simplement passer .update( id, obj ).

Avis de non - responsabilité : je n'ai pas encore essayé de construire un système qui ne contient pas l'identifiant au sein de l'entité et peut donc me prouver le contraire.

Comme GlenH7 l'a noté dans un commentaire, c'est une bonne question, car elle remet en question ce que beaucoup de gens tiennent pour acquis. Mon point de vue, cependant, est que même si le fait d'omettre l'identifiant peut sembler conceptuellement pur, la chose pragmatique à faire serait de conserver l'identifiant avec l'objet sur autant de couches du système que possible. Cela coûte peu, mais peut être utile lorsque les choses commencent à s'effondrer.

Une entité peut ne pas avoir besoin de connaître son identifiant, tout comme une personne n'a pas besoin de connaître son numéro d'identification personnel, son numéro de permis de conduire ni aucun autre identifiant pouvant être utilisé dans votre région. Vous pourriez certainement vous en passer la plupart du temps. Il est cependant sage de porter une sorte d'identification sur vous, au cas où.

La même chose peut être dite d'un objet. Indépendamment des subtilités de la couche d'accès aux données, l'objet est finalement mappé à une certaine entrée de base de données. Cette entrée peut uniquement être identifiée de manière unique par l'ID de l'objet. Si tel est le cas, je préférerais avoir ces informations à ma disposition à tout moment, que je débogue du code d'interface utilisateur, que le nombre soit chiffré dans la couche métier, le référentiel lui-même ou un système dépendant sur un service Web. Ou si je consulte les journaux d'erreurs d'ailleurs.

Dans votre cas, si vous ne récupérez que les données de la base de données et les transmettez via le service Web, il peut être judicieux de ne pas l'identifier. Je ne pense tout simplement pas que cela ait plus de sens que de le garder dans le cas général.

Vous avez raison, vous n'avez pas besoin de stocker l'identifiant dans l'objet, tant que vous n'avez besoin de le connaître que dans votre contexte de référentiel.

La situation change lorsque vous passez l'objet à du code en dehors de ce contexte, du code qui n'a pas demandé l'objet par id (et donc ne le sait pas encore), mais qui a besoin de l'id dans un but quelconque (par exemple, pour le placer sur une liste des identifiants qui seront demandés au référentiel ultérieurement, par encore un autre code).

Dans cette situation, vous avez deux options:

• introduire un nouvel argument de fonction 'id' dans toute la chaîne de fonctions entre le contexte du référentiel et la fonction où l'id est nécessaire

• inclure l'id dans l'objet

Dans la plupart de ces cas, le stockage de l'id à l'intérieur de l'objet sera la meilleure solution. Cela réduira également les changements de code lorsque l'ID est nécessaire dans des endroits imprévus, et il peut parfois être utile pour le débogage.

C'est pourquoi je le fais quand je le fais.