J'ai une classe quelque chose comme ceci:
NHibernate.InvalidProxyTypeException: The following types may not be used as proxies:
Fringine.Users.Account: method SetPassword should be virtual
Fringine.Users.Account: method CheckPassword should be virtual
3 Réponses :
J'ai remarqué que NHibernate s'appuie fortement sur les Pocos pour toutes ses entités. Pour le meilleur ou le pire, je n'ai pas traversé aucun scénario où quelqu'un a brisé cette convention. Davy Brion explique-le en détail ici. (il fait référence à votre point que, oui, vous pouvez marquer des cours comme une charge paresseuse non paresseuse. Mais, puisque NHibernate ne créera aucun de vos proxies, vous êtes coincé.)
Je ne sais pas si cela est utile, mais c'est ainsi que le château le fait. Maintenant que (si vous utilisez 2.1) Vous pouvez choisir le générateur de proxy à utiliser , en déplaçant sur L'un des autres choix pourrait vous permettre de générer des proxies d'une manière qui convient à vos besoins.
Vous pouvez désactiver le chargement paresseux au niveau de la classe et l'activer sur la propriété par la propriété, le chargement paresseux est souvent utilisé pour les relations de collecte-Association.
public class AccountMap : ClassMap<Account>{
public AccountMap()
{
Id( x => x.Id );
Map( x => x.Username )
Map( x => x.Password).Access.AsCamelCaseField();
}
}
public class AccountMap : ClassMap<Account>{
private string password;
public string Password{ get; }
}
Y a-t-il quelque chose de similaire à la carte (x => x.method ()) .not.lazyload ()?
Vous pouvez également désactiver la génération de proxy Vérifier avec cette propriété: utilisez_proxy Validator à False
La raison est que vous pouvez accéder aux champs de vos méthodes, qui ne seront pas initialisés. Donc, le moyen le plus simple est de charger le contenu de l'entité sur n'importe quel appel à l'objet (la seule exception est l'accès à l'ID, qui est déjà disponible dans le proxy).
Vous pouvez donc mettre en œuvre vos méthodes en toute sécurité comme s'il n'y avait pas de mandataire - avec le compromis que la méthode doit être virtuelle (qui - je suis d'accord - n'est pas parfaite).
Si vous pensez qu'il s'agit d'un problème pour votre conception de classe, essayez de déplacer la fonctionnalité à une autre classe (par exemple, PasswordManager, mot de passevalidator, etc.). Cette classe va regrouper le compte ou le supportera comme argument. Le compte ne sera donc chargé que lorsque cette classe appelle réellement l'une de ses propriétés.
Je ne suis pas sûr que cela compte si j'accumule un domaine dans ces méthodes. Lorsque le champ est accessible via une propriété de proxy, elle initialisera l'instance. Les seules propriétés / méthodes qui doivent réellement être virtualisées sont celles qui représentent réellement des colonnes dans la table.
@Paul: Non, vous comprenez mal. Vous peut les champs d'accès directement dans vos méthodes. Il n'y a rien de mal à cela, vous n'avez pas besoin de vous inquiéter de chargement paresseux dans ce cas. Le code de vos entités est toujours exécuté dans une entité entièrement initialisée. Cela rend NH plus transparent. Il est en fait rare d'avoir des membres d'instance qui ne dépendent pas de l'état de l'instance. Il existe donc un espace très limité pour optimiser.
Ahh, j'ai mal compris. La protection de l'accès au champ a du sens.