Je souhaite que NHibernate appelle une procédure stockée lorsque ISession.Get est appelée pour récupérer une entité par sa clé au lieu d'utiliser SQL dynamique. Nous utilisons NHibernate et lui permettons de générer notre SQL pour les requêtes et les insertions/mises à jour/suppressions, mais nous devons maintenant déployer notre application dans un environnement qui nécessite l'utilisation de procédures stockées pour tous les accès à la base de données. Nous pouvons utiliser sql-insert, sql-update et sql-delete dans nos fichiers de mappage .hbm.xml pour les insertions/mises à jour/suppressions. Nos requêtes hql et critères devront être remplacées par des appels de procédures stockées.NHibernate avec rien d'autre que des procédures stockées
Cependant, je n'ai pas compris comment forcer NHibernate à utiliser une procédure stockée personnalisée pour récupérer une entité avec sa clé. Je veux toujours être en mesure d'appeler ISession.Get, comme dans:
using (ISession session = MySessionFactory.OpenSession())
{
return session.Get<Customer>(customerId);
}
et aussi des objets de charge paresseux, mais je veux NHibernate appeler mon « GetCustomerById » procédure stockée au lieu de générer le SQL dynamique.
Est-ce que cela peut être fait?
Peut-être que NHibernate n'est plus adapté compte tenu de ce nouvel environnement que nous devons supporter.
Honnêtement vous avez vraiment besoin de changer l'environnement, ces proc stockées Les exigences sont absolument stupides, elles n'offrent aucun avantage en termes de sécurité et de performance et pourraient facilement ajouter des semaines, voire des mois, d'heures de développement à votre projet. Cela ressemble à un défaut de gestion. –
Je suis d'accord avec Chris. Je ne sais pas si c'est une décision de gestion, mais utiliser SP pour l'utiliser n'est pas exactement une bonne pratique à plusieurs égards. –
Je suis d'accord sur le fait que les SP sont un mauvais choix. J'ai introduit NH pour éviter d'écrire des centaines de proces stockés et pour augmenter notre productivité et ça a été génial. Il est vu par quelqu'un sur le site du client comme une exigence de sécurité pour empêcher l'injection SQL, je suppose. Il peut s'agir de la gestion, d'un administrateur de base de données, d'une infrastructure/TI, mais je n'ai pas été en mesure de communiquer avec le décideur ultime. De toute évidence, l'injection SQL peut toujours poser un problème dans les SP contenant du SQL dynamique. La stratégie peut donc générer un faux sentiment de sécurité. – ChrisB2010