Lorsque vous fournissez une méthode de logique métier pour obtenir une entité de domaine, le paramètre doit-il accepter un objet ou un ID? Par exemple, devrions-nous faire ceci:
public Foo GetItem(int id) {}
ou ca:
public Foo GetItem(Foo foo) {}
Je crois en la possibilité de faire circuler des objets dans leur intégralité, mais qu'en est-il du cas où nous obtenons un objet et que nous ne connaissons que l'identifiant? L'appelant doit-il créer un Foo vide et définir l'ID, ou doit-il simplement transmettre l'ID à la méthode? Puisque le Foo entrant sera vide, à l'exception de l'ID, je ne vois pas l'avantage pour l'appelant de devoir créer un Foo et définir son ID lorsqu'il pourrait simplement envoyer l'ID à la méthode GetItem ().
la source
Est-ce que cela va passer par le fil (sérialisé / désérialisé) à tout moment maintenant ou à l'avenir? Privilégiez le type d'identifiant unique par rapport à l'objet complet who-know-how-large.
Si vous recherchez une sécurité de type de l'ID vers son entité, il existe également des solutions de code. Faites-moi savoir si vous avez besoin d'un exemple.
Edit: développer la sécurité de type de l'ID:
Alors, prenons votre méthode:
Nous espérons seulement que le nombre entier
id
transmis est destiné à unFoo
objet. Quelqu'un pourrait en abuser et transmettreBar
l'ID entier d' un objet ou même simplement à la main812341
. Ce n'est pas sûr de taperFoo
. Deuxièmement, même si vous utilisiez le passage uneFoo
version d’ objet , je suis sûrFoo
qu’un champ d’identification est celuiint
que quelqu'un peut éventuellement modifier. Enfin, vous ne pouvez pas utiliser la surcharge de méthodes si elles existent dans une classe, car seul le type de retour varie. Réécrivons un peu cette méthode pour avoir une apparence de type sécurisé en C #:J'ai donc introduit une classe nommée
IntId
qui contient un élément générique. Dans ce cas particulier, je veux unint
qui est associé àFoo
seulement. Je ne peux pas simplement passer nuint
et je ne peux pas lui attribuer unIntId<Bar>
accidentellement. Voici donc comment j'ai écrit ces identifiants de type sécurisé. Prenez note que la manipulation du sousint
- jacent réel n’est que sur votre couche d’accès aux données. Tout ce qui est au-dessus ne voit que le type fort et n'a pas d'accès (direct) à sonint
ID interne . Il ne devrait y avoir aucune raison deInterface IModelId.cs:
ModelIdBase.cs classe de base:
IntId.cs:
et, par souci d'exhaustivité de ma base de code, j'en ai aussi écrit un pour les entités GUID, GuidId.cs:
la source
Origin
propriété: cela ressemble beaucoup à un schéma dans le jargon de SQL Server. Vous avez peut-être unFoo
logiciel utilisé dans votre logiciel de comptabilité et un autreFoo
destiné aux ressources humaines. Il existe peu de champs pour les distinguer au niveau de votre couche d'accès aux données. Ou, si vous n’avez pas de conflit, ignorez-le comme moi.Je suis certainement d'accord avec votre conclusion. Passer un identifiant est préférable pour certaines raisons:
Foo
objet juste pour l'id signifie créer de fausses valeurs. Quelqu'un peut faire une erreur et utiliser ces valeurs.int
est plus large et peut être déclaré nativement dans toutes les langues modernes. Pour créer unFoo
objet à l'aide de l'appelant de méthode, vous devrez probablement créer une structure de données complexe (comme un objet json).la source
Je pense que vous seriez sage d’établir la recherche sur l’identifiant de l’objet, comme l’a suggéré Ben Voigt.
Cependant, rappelez-vous que le type d'identifiant de votre objet peut changer. En tant que tel, je créerais une classe d'identifiant pour chacun de mes éléments et n'autoriserais que la recherche d'éléments via ces instances de ces identificateurs. Voir l'exemple suivant:
J'ai utilisé l'encapsulation, mais vous pouvez aussi faire
Item
hériter deItemId
.Ainsi, si le type de votre identifiant change en cours de route, vous ne devez rien changer à la
Item
classe ni à la signature de la méthode GetItem. Ce n'est que dans la mise en œuvre du service que vous devrez changer votre code (ce qui est la seule chose qui change dans tous les cas de toute façon)la source
Cela dépend de ce que fait votre méthode.
En règle générale
Get methods
, il est de bon sens de passerid parameter
et de récupérer l'objet. En attente de mise à jour ouSET methods
d’envoi de l’ensemble de l’objet à définir / mettre à jour.Dans certains autres cas où votre
method is passing search parameters
(en tant que collection de types primitifs individuels) pour récupérer un ensemble de résultats, il peut être judicieux de définiruse a container to hold
vos paramètres de recherche. Ceci est utile si, à long terme, le nombre de paramètres change. Ainsi, vouswould not need
changez lesignature of your method, add or remove parameter in all over the places
.la source