Modèle de référentiel avec Entity Framework 3.5 et MVVM - Devrais-je partager le même contexte partout?

c# entity-framework mvvm repository-pattern wpf

Question

Je développe un système de fichiers de base de données . J'utilise -

  1. .Net framework 3.5
  2. Entity Framework 3.5
  3. WPF avec modèle MVVM

Le projet s'étend sur plusieurs assemblages utilisant chacun le même modèle.

Un ensemble, appelons-le un "serveur", ajoute uniquement des données à la base de données en utilisant EF, c'est-à-dire le même modèle. D'autres ensembles (y compris l'interface utilisateur) lisent et écrivent les données.

La base de données contient des tables d'auto-référencement dans lesquelles chaque entité peut avoir un seul OU aucun parent et (éventuellement) des enfants. Je souhaite utiliser un modèle de référentiel, qui peut également fournir un mécanisme permettant de gérer cette nature hiérarchique.

J'ai déjà lu sur Code Project . Il partage le même contexte (entités) partout.

Ma question est la suivante: devrais-je partager le même contexte partout? Quels sont les avantages et les inconvénients de cela?

Réponse acceptée

L'exemple BookLibrary du cadre d'application WPF (WAF) montre comment vous pouvez utiliser WPF MVVM et Entity Framework ensemble. Il sépare les couches en assemblages individuels.

Peut-être que c'est ce que vous recherchez.


Réponse populaire

D'après ce que je comprends, le contexte d'objet devrait être utilisé en cas de besoin, puis jeté. vous voudrez donc probablement l’envelopper dans une unité d’interface de travail, avec une unité d’usine de travail, pour créer l’unité d’œuvres en cas de besoin.

En ce qui concerne votre question sur les entités reflétant les modifications apportées aux "assemblées". La chose est que vos objets ne vivent pas existe dans les assemblées. Ils existent en mémoire.

Ainsi, pour que les modifications soient reflétées dans toute l'application, vous devez soit conserver une référence au même objet dans l'ensemble de votre application. Vous pouvez également implémenter un système de notification afin que, lorsqu'une entité ou un ensemble d'entités est modifié, l'autre côté de votre application notifie et actualise les données.

L'inconvénient de garder un seul contexte actif est que chaque fois que vous effectuez des requêtes sur le contexte de l'objet, il grandit avec les entités chargées à partir de la base de données. Dans une application de longue durée, cela se traduit par une consommation de mémoire importante.

L’inconvénient d’utiliser chaque fois un tout nouveau contexte est que tout appel au référentiel vous donne une nouvelle copie des données. Maintenant, cela ne devrait pas être un problème puisque, puisque la seule préoccupation du référant devrait être la sauvegarde / chargement des données; ne pas gérer la simultanéité ou la duplication de données sur plusieurs couches



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow