Comment stocker l'élément temporaire dans ObjectContext sans enregistrer sur la base de données?
Contexte Stockage dans httpcontext, en fournissant par classe: Il y a deux pages vides:
1) FirstPage.aspx.cs: donc, comtinInfirspage = 1. 2) secondpage.aspx.cs : ici comtininsecondpage = 0. où je me trompe?
3 Réponses :
suis-je raison que la deuxième page est une deuxième demande?
Dans ce cas, vous avez une nouvelle collection httpcontext.items et vos valeurs de la dernière demande sont terminées. Pensez à utiliser une session pour stocker ces valeurs dans un tel cas.
Note de bas de page: l'entitéContext ne doit être utilisé que pour une demande et peut être stockée dans la collection httpContext.items pour cette raison mais jamais comme une valeur de session! Stocker juste des résultats ici comme le comte.
OUI, SEATPAGE Ciblage du FirstPage par lien ... Essayer d'utiliser la session
Ça marche! J'ai refait le httpcontextextension via httpcontext.session. Merci!
À propos de la note de bas de page: pourquoi je ne devrais pas stocker l'entitéContext comme valeur de session?
Ce n'est rien de nouveau et j'ai juste besoin de citer @Brokenglass mais même s'il était possible de stocker le contexte de la DB de cette façon, c'est-à-dire même si vous avez décidé de le stocker à la session - ce n'est pas la voie à suivre - la portée de chaque contexte devrait être une seule unité de travail, vous ne devez pas le garder en vie pendant une période prolongée, en particulier dans un environnement Web. Il est vraiment mauvais de garder votre entitéContext vivant dans un environnement Webenvironment. Vous devriez Toujours le laisser tomber et il suffit de stocker des résultats que vous pourriez avoir besoin plus tard. Il y a tellement de contre qui ne correspond jamais à ce commentaire.
Vous ne perduisez pas autant de performances lors de la configuration de l'entitéContext Nouveau avec chaque demande. Et dans votre exemple, vous avez juste besoin du nombre de comptes dans la prochaine demande. Vous pouvez également stocker ces valeurs comme obtenir des params dans le lien qu'est-ce qui vous libère d'une session. Avec cela, ils seront disponibles à la vue suivante. À mon avis, ce serait la solution la plus propre pour votre cas. La valeur stocke exactement où vous avez besoin. Peu importe s'il n'y ait qu'un ou des centaines
J'espère que les commentaires vous aide!
Merci de votre aide. Mais non seulement compter nécessaire pour être adopté entre les pages. Dans mon projet, j'ai besoin de créer des entités référencées dans différentes pages contextuelles. Dans la deuxième page, je crée un type d'élément de Myenttity2 qui doit être référencé à l'élément de la myentity (créé dans la première page), puis transmettez-la en arrière à la première page. Donc, je ne peux pas passer uniquement la clé de l'élément de référencement, car il suffit de créer une entité liée.
Il y a un très bon livre sur l'entitéFramework 4 de Julie Lerman Vous devez le lire.
Pour exécuter une requête sur vos nouvelles données à l'aide d'EF, vous devrez économiser. Vous aurez peut-être à une liste de répercuter ensuite la requête sur la liste, mais cela vous obligera à conserver la liste dans une sorte de mémoire statique (état de session, visualisation, cache), mais si la liste est grande qui peut créer d'autres problèmes.
Vous pouvez tout faire dans un transaction . Transmettre la transaction jusqu'à ce que vous vous engagiez soit commetter. Les objets d'entité sont enregistrés mais lorsque la transaction est renvoyée, les modifications sont annulées. Je pense que la transaction persistera par des post-retours et des redirections, mais devra être commis ou disposée au moment de votre page rendu.
Voulez-vous dire «passer la transaction autour» == Passez-le entre les pages? Je pensais que cela ne fonctionne qu'avec une entitéContext ...
Ceci est la mauvaise approche, Mais même s'il était possible de stocker le contexte de DB de cette façon, c'est-à-dire même si vous avez décidé de le stocker au cours de la session - ce n'est pas la voie à suivre - la portée de chaque contexte devrait être une seule unité de travail, Vous ne devriez pas le garder en vie pendant une période prolongée, en particulier dans un environnement Web.
Il suffit de sauvegarder vos éléments temporaires dans la session directement et créez un nouveau contexte pour télécharger ces éléments lorsque vous êtes prêt à. httpcontext ne dispose d'une portée d'une seule demande HTTP, de sorte que vous traitez avec un contexte différent dans la deuxième demande.
-1 La session est une solution médiocre pour un objet-cadre d'entité. EF n'envoie que sur une base si nécessaire, de sorte que tout objet enfant n'existerait pas et lorsque vous appelez la méthode de modification de sauvegarde pour l'EF, cela échouera.
Pour autant que je puisse dire au-dessus de l'instance de classe, c'est une classe d'entité sans d'autres dépendances et non attachée à un contexte, de sorte que vous pouvez enregistrer une autre instance de classe dans la session, vous devriez pouvoir faire de même avec celui-ci. Je ne comprends pas bien votre préoccupation.
Il a besoin de récupérer l'objet modifié dans la requête sur la deuxième page que je suppose que je suppose pour une commande de contrôle.
@Chad Yep, je vais utiliser cette valeur pour la lier à comboBox dans la deuxième page. Une autre manière est de passer des valeurs via la session entre les pages et fixer des valeurs reçues au contexte, non?
@Brokenglass Je ne vois rien de mal dans votre message. Dunno ce que Tchad signifie. donc +1