pendant un moment, j'ai réfléchi à la manière de faire face aux objets qui sont attribués des identificateurs de la base de données.
Un objet typique représentant une entité de table peut ressembler à: p>
public class Test
{
public int Id { get; private set; }
public string Something { get; set; }
}
3 Réponses :
Donc, vous avez une classe qui contient l'identifiant de la table de base de données en tant que champ, donc en cas de récupération / de suppression et de mise à jour de votre identifiant d'entité est aligné sur l'identifiant de l'enregistrement de base de données. En cas d'insertion, vous pouvez récupérer la valeur d'identification de l'enregistrement simplement inséré et mettre à jour votre entité avec cette valeur. Vous pouvez donc avoir des procédures de magasin distinctes pour l'insertion / la mise à jour / la récupération et la suppression. L'insertion SP pourrait vous rappeler l'identifiant de l'enregistrement simplement inséré sous la forme d'un paramètre ou de code>. J'espère que je réponds à votre question.
Je suis d'accord avec l'affirmation d'Abdul, que c'est la responsabilité de la DB de déterminer de nouvelles valeurs d'identifiant et de définir toutes les autres défauts correspond à de nouveaux enregistrements. Vous devez demander une nouvelle ligne à partir de la base de données, puis permettez à l'utilisateur de modifier la nouvelle ligne, si elles le souhaitent.
L'objet serait certainement attribué à un identifiant après avoir été inséré dans la base de données et cet ID pourrait être défini sur l'objet inséré. Cependant, je vois toujours un problème représentant l'objet avant l'attribution d'un identifiant.
Alors, quel est le problème que vous voyez?
Si vous traitez Si ce n'est pas (comme dans, la propriété de l'objet est motivée par des besoins professionnels) - si Vous pouvez toujours envelopper vos propriétés d'objet dans une classe distincte, si vous sentez que disposer d'objets sans Cette question (ou plutôt ma réponse sur les paramètres d'emballage) m'a rappelé un fait qui m'a une fois surpris. Quand un enfant est né, elle n'existe pas dans le système jusqu'à ce que ses parents ne l'enregistrent officiellement et elle obtient numéro d'identification personnel attribué. Donc, techniquement, sans ID comme moyen d'identifier / accorder l'unicité à l'objet de votre application, cela devrait être géré par la base de données ( sauf si bien sûr, vous avez d'autres moyens attribuer des identifiants aux objets).
0 est valide / bonne valeur de conception ou non dépend de ces besoins en matière d'entreprise. Est-ce que 0 Valeur valide de Say, point de vue de l'utilisateur final?
IDS définis dans votre application est problématique. Vous utiliserez une telle classe essentiellement uniquement pour les paramètres de transport pour pas encore objet créé (processus de création étant finalisé avec l'insert de base de données). Une fois que l'objet est inséré, ID attribué et trucs - vous pouvez travailler avec votre entité ordinaire. Votre utilisateur va-t-il aller "Oh, Snap! Qu'est-ce que c'est?" ou "ok .. Je sais quoi faire." une fois approché par id = 0 < / code>?
ID - l'enfant n'existe pas (au moins du point de vue du système), même que tout le monde sait qu'elle est née et que c'était des trucs. C'est la même chose avec la base de données / votre application - objet sans ID (une que la base de données ne puisse pas identifier) n'existe pas - il s'agit simplement d'un ensemble de paramètres. Bit Bizzare, mais j'espère que mon point est clair :)
Il n'y a rien de mal à concevoir une classe de sorte qu'un identifiant de 0 indique que l'entité n'a pas encore été sérialisée. J'ai construit des systèmes dans le passé qui utilisaient avec succès cette approche. Assurez-vous simplement que ces sémantiques sont bien définies dans votre API et que cette signification est respectée dans tout le code.
Un piège à surveiller est l'utilisation de l'ID pour définir une relation d'égalité (telle que pour générer des codes de hachage pour un dictionnaire). Cela ne doit être fait que pour les ID non nuls. Pour tester l'égalité avec deux identifiants de zéro, l'égalité de référence peut être utilisée. P>
Cependant, étant donné que des entités non construites peuvent avoir leur changement d'identité à un moment donné à un moment donné, il est très important que de tels objets ne soient jamais stockés dans un dictionnaire. Ou, à tout le moins, de tels articles doivent être supprimés de tout dictionnaire avant d'enregistrer puis de restaurer ensuite à l'aide de l'identifiant nouvel identifiant. P>
Avec cette réservation, cette conception devrait fonctionner correctement. P>
public class Test : IEquatable<Test>
{
/// <summary>
/// The unique identifier for this Test entity, or zero if this
/// Test entity has not yet been serialized to the database.
/// </summary>
public int Id { get; private set; }
public string Something { get; set; }
public override bool Equals(object obj)
{
return Equals(obj as Test);
}
public bool Equals(Test other)
{
if (other == null)
return false;
// Distinct entities may exist with the Id value of zero.
if (Id == 0)
return object.ReferenceEquals(this, other);
return Id == other.Id;
}
/// <summary>
/// Gets a hash code for this Test entity. Warning: an instance with
/// an Id of zero will change its identity when saved to the DB. Use with care.
/// </summary>
/// <returns>The hash code.</returns>
public override int GetHashCode()
{
return Id;
}
}
Je me rends compte qu'un identifiant de 0 indiquant qu'un objet n'a pas d'identification est certainement une solution de travail valide; Je me demandais simplement si je serais réalisable de faire quelque chose de mieux. Je crois qu'il est toujours préférable de ne pas autoriser les données "incorrectes" et de les documenter, par opposition à ne pas être possible du tout.
@Dehas - Oui, c'était l'une des options de votre question initiale. Je disais juste que, à mon avis, tout va bien. Je ne vois aucune distinction entre la définition de 0 comme non sauvé et définissant Null de cette façon, sauf que le premier est légèrement moins difficile que la seconde. À mon avis, documenter et mettre en œuvre correctement une valeur spéciale est une bonne solution.
@Dehas - Pensez à cette façon: dans un double le premier bit est interprété pour indiquer si la valeur numérique est positive ou négative. C'est cependant un peu comme n'importe quel autre et peut être interprété d'autres moyens d'autres contextes. Définir certaines combinaisons de bits en tant que sens, une chose par opposition à une autre chose est une partie fondamentale de la programmation et n'indique pas de mauvaise conception.
Il n'est pas possible d'obtenir un objet sans identifiant, s'il a été récupéré à partir de la base de données. Comme vous l'insérez, il obtiendra une pièce d'identité immédiatement (sauf si vous avez une base de données réaublement étrange)
@ XS0 évidemment. Cependant, il est possible de regarder strictement la définition du type d'objet.
Eh bien, vous dites le contraire dans votre question .. Mais de toute façon, que voulez-vous faire avec ces objets? Sauf si vous expliquez quelles opérations seront faites avec elles, on ne sait pas ce que le problème est ..
Utilisez-vous l'ensemble de l'entité ou avez-vous simplement voulu dire «entité» au sens général?
Je veux dire l'entité en général, bien que le problème existe évidemment lors de l'utilisation également de l'entité.