Entité-Framwork-4 - l'accès à la propriété clé étrangère lorsque le contexte est parti en vue ASP.NET MVC2

J'ai une base de données avec ce tableau:Entité-Framwork-4 - l'accès à la propriété clé étrangère lorsque le contexte est parti en vue ASP.NET MVC2

Customer 
- ID 
- Phone 
- Cell 
- Fax 

PhoneList 
- ID 
- PrefixID 
- Number 

Prefix 
- ID 
- Number

Il y a un FK entre le client chaque colonne de téléphone à PhoneList ID (et un autre de prefixID à ID sur le préfixe de table)

J'ai importé la base de données dans le fichier edmx en utilisant VS2010. J'ai obtenu des propriétés PhoneList, PhoneList1, PhoneList2 - généré (Q1: comment je change cela à d'autres noms?) Dans une bibliothèque de classe modèle ASP.NET MVC-je obtenir la liste des clients en utilisant:

clients var = de c en contexte. Les clients sélectionnent c;

et envoyer le résultat au contrôleur:

customersTable.AsQueryable de retour(); Le problème: je peux accéder à toutes les propriétés habituelles du client dans la vue, mais une fois que j'accède à PhoneList (généré automatiquement qui représente l'objet numéro de téléphone), j'obtiens cette erreur, car le contexte a disparu depuis longtemps et s'est fermé. côté modèle:

The ObjectContext instance has been disposed and can no longer be used for operations that require a connection.

Q2: Comment dois-je faire face à cette situation - Comment puis-je assurer que les données que j'ai besoin « Stays »/Retreived de la base de données (et de l'autre côté, un autre FK que je don pas besoin d'être chargé - ne pas être chargé)

(Q2- est la "vraie" question, réponse o n Q1 sera apprécié ...)

Je travaille avec ASP.NET MVC2, EF-4

Merci.

Source

2010-12-21 Dani

Vous ne devez pas utiliser les classes Entity Framework dans vos vues. Vous devez définir et utiliser des modèles de vue. Les modèles View sont des classes spécialement conçues pour les besoins d'une vue donnée. Ainsi, vous pouvez avoir plusieurs modèles de vue du même modèle (voir les modèles sont un sous-ensemble du modèle) ou un seul modèle de vue mappé à plusieurs classes de modèles (dans ce cas, le modèle de vue est un surensemble de plusieurs modèles). Donc, fondamentalement, vous auriez un référentiel qui s'occupera d'extraire le modèle de quelque part (base de données, fichier, service distant, ...), puis convertira ce modèle en modèle de vue et passera ce modèle de vue au contrôleur.

Donc dans votre référentiel vous pouvez eagerly load les entités enfants pour éviter d'avoir ce genre d'exceptions.

Vous décorerez alors vos classes de modèle de vue avec les attributs d'affichage nécessaires qui seraient spécifiques à la vue donnée. Vous pouvez utiliser AutoMapper pour convertir entre vos modèles et voir les modèles.

Source

2010-12-21 19:15:32

q. Viewmodels doit définir Dans le projet d'interface utilisateur, lorsque je peuplais le viewmodel, ne serais-je pas confronté au même problème?Si je comprends bien la 2ème partie de votre réponse, est-ce que je devrais créer une classe de modèle à chaque classe d'EF et la remplir et la passer au lieu de la classe générée automatiquement et ces classes seront les sous-ensembles de mes viewmodels? N'est-ce pas un "gâchis" du modèle généré automatiquement par EF? – Dani

@Dani, oui les modèles de vue doivent être définis dans le projet d'interface utilisateur car ils sont liés à une vue. Vous devez créer un modèle de vue spécifique aux besoins de la vue et transmettre ce modèle de vue à la place de la classe EF. Et non ce n'est pas une perte de classes de modèles générés automatiquement. –

@Darin, Pour être sûr de bien comprendre - j'ai besoin de définir une classe de modèle dans le projet modèle, la remplir avec les données de la classe Auto-Generated que je reçois de linq, envoyer cette classe à l'interface utilisateur et là je vais mettre à l'intérieur d'une vue-modèle qui sert mes besoins de vue. donc j'ai une classe de client de l'edmx, une classe de client que j'ai créée manuellement dans le projet de modèle, et alors j'aurai la dernière classe à l'intérieur du viewmodel pour cette vue spécifique. Est-ce la bonne façon d'y aller? – Dani

Q1: Vous devriez pouvoir modifier les noms avec l'éditeur qui s'ouvre dans Visual Studio lorsque vous double-cliquez sur le fichier EDMX.

Q2: soit garder le contexte ouvert (si c'est une option), ou utiliser Inclure méthode qui est accessible pour vous (ne me souviens pas si elle est éteinte IDbSet ou ObjectQuery

Source

2010-12-21 19:19:09

Merci , À propos de Q1 - lorsque je mets à jour l'EDMX en raison de changements de DB, ces changements manuels vont-ils rester? à propos de Q2- il serait faux de garder le contexte ouvert .... Je vais chercher ce que signifie la méthode signifie .. – Dani

Après avoir dit "garder le contexte ouvert" j'aurais dû mettre "mais assurez-vous de le nettoyer correctement lorsque vous êtes Si vous utilisiez IoC, cela aurait plus de sens À propos de QA1: L'un des principaux objectifs de EF est de ne pas exiger que votre modèle d'objet corresponde à votre modèle de base de données, ce qui devrait être très possible. de vos objets, la forme de votre modèle de base de données, et un mappage entre les deux. –

Entité-Framwork-4 - l'accès à la propriété clé étrangère lorsque le contexte est parti en vue ASP.NET MVC2

Répondre

Questions connexes