NHibernate: Valeur par défaut pour une propriété sur une colonne nulle

Question

Je travaille avec une ancienne base de données utilisée par d'autres applications, donc je ne peux pas modifier sa structure. Parfois, j'ai des colonnes nullables que je veux mapper en tant que type non nullable. Par exemple, j'ai une colonne EndValidity Nullable sur la base de données que je veux mapper sur un DateTime non nullable, et, si null, il devrait être DateTime.MaxValue, ou comme un exemple plus simple, une colonne de bits Nullable qui doit être false si nul.

Je pense à écrire un type d'utilisateur personnalisé (avec des paramètres si possible), ou y at-il quelque chose d'inclus dans nHibernate?

Si la seule solution est d'écrire un type d'utilisateur personnalisé, pour le cas booléen, puis-je remplacer les conventions fluentnhibernate pour toujours appliquer ce type d'utilisateur pour les booléens?

Answer 1

Cela dépend probablement de la façon dont vous voulez que votre classe poco agisse. Tout d'abord, si vous chargez une valeur nulle, voulez-vous que la valeur NULL soit réenregistrée ou voulez-vous que la validation/vidage de session mette à jour l'enregistrement avec la nouvelle valeur par défaut pour le champ NULL. Si vous voulez conserver la valeur nulle dans la base de données, comment détecteriez-vous votre objet poco avec juste une valeur booléenne pour enregistrer IE? Les booléens n'ont que des options/valeurs vraies et fausses mais votre classe de bits a les options/valeurs de null. 0 et 1? Si dis: vous voulez avoir vos bits nullables comme une valeur booléenne et non une valeur booléenne nulleable dans votre classe poco et que la classe mette à jour la db pour supprimer tous les nulls alors une solution qui est assez rapide sans plonger dans la custom types est d'avoir les deux propriétés un nullable et protégé ou interne et une propriété dans une interface (sans aucun mappage) avec la logique de base - pour des raisons de dépendance injecte toutes les classes poco auraient idéalement une interface ou deux: EG

internal virtual bool? isActive {get;set;} 
public bool MyInterface.IsActive 
{ 
    get{ return isActive ?? false; } 
    set{ isActive == value ?? false; }; 
} 

De cette façon, votre logique est contenue dans le code, donc si les règles deviennent plus complexes/compliquées ou un bit nullable a une valeur par défaut de false mais un autre a un défaut de vrai (à cause d'un développeur fou du siècle dernier), vous pouvez plus facilement contrôler les transformations. Il vous faudra travailler avec des interfaces au lieu des vraies classes poco, mais encore une fois ce n'est pas une mauvaise chose, cela dépend simplement de votre modèle de développement.