2010-08-28 4 views
1

Entity Framework permet de mapper facilement le résultat d'une procédure stockée sur une Entité. Ce que je besoin est de mapper une entité aux paramètres d'entrée, de sorte qu'au lieu deEntity Framework fonction import: mappage des paramètres d'entrée

context.SaveUser(user.FirstName, user.LastName, ...); 

je peux simplement l'appeler comme ceci:

context.SaveUser(user); 

Ce que je veux vraiment est d'isoler les changements possibles de schéma autant comme je peux. J'utilise seulement EF pour générer des entités et des importations de fonctions; toute l'interaction avec DB est effectuée via des appels de fonction. Donc, chaque fois que la table des utilisateurs change, je veux régénérer l'entité utilisateur dans le concepteur visuel et modifier le code de logique métier, selon le cas; Je ne veux pas changer la couche d'accès aux données. Actuellement, je ne vois aucun moyen de contourner ces appels dépendant de l'ensemble de données de la couche d'accès aux données vers EF (comme celui que j'ai posté ci-dessus), ce qui est dommage car ils pourraient facilement être régénérés avec les classes d'entités.

Y a-t-il une autre stratégie qui me permettrait d'atteindre le même objectif? La raison pour laquelle j'utilise ces procédures stockées est en fait parce que je veux avoir un contrôle total sur SQL (peut-être que je suis juste paranoïaque, mais il est assez effrayant de se retrouver avec des piles de code LINQ avec peu ou pas de contrôle réel SQL).

Est-ce possible?

Merci

Répondre

0

je ne pense pas qu'il soit possible sans un code supplémentaire boilerplate. Peut-être que vous devriez repenser votre stratégie d'accès actuelle et ne pas utiliser les procédures stockées. Ensuite, vous serez en mesure de le faire comme vouloir.

0

Ceci est possible mais de manière différente que vous essayez de l'atteindre. Chaque entité permet de mapper les actions d'insertion, de mise à jour et de suppression aux procédures stockées. Donc, dans votre cas, je suppose que vous devez créer un mappage pour l'action Insérer et mettre à jour à la procédure stockée SaveUser. Lorsque le mappage est terminé, la procédure stockée est appelée en interne chaque fois que l'entité est ajoutée ou mise à jour dans l'ensemble d'entités et que SaveChanges est demandé. Ainsi, vous travaillerez avec l'ensemble d'entités de la même manière que sans procédures stockées. Vérifiez ces articles sur MSDN: How to et Walkthrough.

Edit:

Essayez d'utiliser l'approche mentionnée et enregistrer les modifications de cette façon:

var user = new User(); 
FillUser(user); // fill modified data to user entity 

using (var context = new MyContext()) 
{ 
    context.Users.Attach(user); 
    context.ObjectStateManager.ChangeObjectState(user, EntityState.Modified); 
    context.SaveChanges(); // This should call your Update stored procedure 
} 
+0

C'est ce que je voulais faire au départ, mais la chose est, pour insérer, mettre à jour ou supprimer une entité dont vous avez besoin pour l'obtenir du contexte en premier. Il n'y a pas d'action Select à mapper sur une procédure stockée et mon utilisateur n'a pas d'autorisation Select sur la base de données. Sorte de toute l'idée ... – tokaplan

+0

Pourquoi pensez-vous que vous devez d'abord obtenir l'entité du contexte? –

+0

Eh bien, peut-être pas à chaque fois, mais la plupart du temps - à moins que je ne crée une nouvelle entité, bien sûr. Le scénario type consiste à extraire une entité de la base de données, à faire quelque chose avec elle et peut-être à la sauvegarder. EF essaie de générer une requête SQL chaque fois que j'essaie d'obtenir une entité de la base de données, et il semble qu'il n'y ait aucun moyen de faire appel à une procédure stockée à la place. Je n'ai pas besoin d'EF pour faire tous les JOINs pour moi, je le ferai dans un SP s'il le faut. – tokaplan

Questions connexes