Vues et procédures stockées - utilisation des deux pour la sécurité DB (Entity Framework 4)

Question

Je suis un peu nouveau pour la programmation de base de données en général, et même plus récent pour Entity Framework 4. Je lis le livre d'O'Reilly Press sur le sujet, et je veux juste être sûr que je comprends ce que l'auteur dit à propos de l'utilisation des vues en conjonction avec les procédures stockées pour une couche de sécurité supplémentaire. Elle dit:

Si vous êtes réticent à exposer vos tables de base de données pour l'interrogation, vous n'avez pas à le faire. ... Les vues viennent dans le modèle en tant qu'entités, mais parce que les vues sont en lecture seule, Entity Framework n'est pas capable de construire des commandes pour conserver les données dans la base de données lorsque vous appelez SaveChanges. ... Cependant, ces entités participent toujours au suivi des changements, comme toutes les autres entités (avec une mise en garde sur EntityKeys dont je parlerai dans un instant). Vous pouvez ensuite mapper des procédures stockées sur ces entités basées sur une vue afin de conserver les données lorsque vous appelez SaveChanges. Cela vous donne un aller-retour complet pour interroger et mettre à jour les données sans exposer vos tables de base de données.

J'ai quelques difficultés à comprendre comment ce mappage de procédure stockée fonctionnerait puisque les vues sont en lecture seule. Est-elle en train de dire que les procédures stockées seraient mappées aux entités représentées par la vue, avec les procédures d'insertion, de mise à jour et de suppression mappées à la base de données et la procédure de sélection mappée à la vue?

Answer 1

Ceci est une exigence courante dans les environnements de base de données hébergés. En gros, cela fonctionne de cette façon:

• vous sélectionnez vos données de vues
• vous utilisez des procédures stockées pour INSERT, UPDATE, DELETE

Entity Framework 4 prend en charge bien ces exigences et permet pour créer des solutions qui ne nécessitent aucun accès direct à la table pour votre application (et ses utilisateurs). Cela peut être un gros plus dans les environnements et les industries sensibles.

Vous importeriez essentiellement les vues dans votre modèle EF. Chaque vue crée alors une entité (une classe) dans votre modèle. Pour chacune de ces entités, vous pouvez ensuite mapper les opérations INSERT, UPDATE, DELETE sur des procédures stockées existantes dans la base de données.

Voir l'article Deny Table Access to the Entity Framework Without Causing a Mutiny dans le magazine MSDN pour une explication plus détaillée des tenants et aboutissants de ce document. Il explique toutes les étapes dans les moindres détails.