Save One, Enregistrer tout dans Entity Framework

Question

Je suis encore à apprendre à propos de l'unité des modèles de travail, les modèles du référentiel, etc.

Mon application:

• J'ai une liste d'entités, dites clients un listview
• Lorsque je sélectionne un client un formulaire de détail montre, où les détails peuvent être modifiés

J'essaie de comprendre la manière standard MVVM/Entity Framework d'accomplir la followin g:

• Lorsque l'utilisateur édite un client, il montre que « changé » (mais pas enregistré)
• L'utilisateur peut choisir soit enregistrer le client actuel ou enregistrer tous les clients modifiés
• Save ou Enregistrer toutes les commandes/boutons sont désactivés si cette option n'est pas disponible (le client actuel est inchangé ou tous les clients sont inchangés)

Semble-t-il assez simple? Mais je n'ai aucune idée de la façon d'aborder cela en utilisant MVVM/EF. Est-ce que j'utilise UoW, est-ce que je détache des objets et me rattache au contexte pour que je puisse les sauvegarder un à la fois? Comment puis-je détecter si un objet est modifié ou non?

Aide! Merci!

Answer 1

j'fous dans quelques remarques:

Le point critique de vos besoins est à mon avis la possibilité d'enregistrer l'un client ou tout changé clients. Vous devez prendre en compte que Entity Framework n'a pas de méthode pour enregistrer les modifications d'un seul ou de quelques objets sélectionnés dans le contexte. Vous pouvez enregistrer uniquement les modifications de l'ensemble de l'unité de travail (ObjectContext ou DbContext dans EF) en appelant le myContext.SaveChanges(). Cela conduit à la conclusion que vous ne pouvez pas utiliser la liste de tous les clients et le formulaire détaillé du client dans une seule unité de travail (= contexte EF) qui détient tous les clients en tant qu'entités attachées. Si vous le faites, vous pouvez fournir une fonction/bouton pour enregistrer tous les changements mais pas une option pour enregistrer uniquement le client actuel dans le formulaire. Donc, soit je pense que si vous avez vraiment besoin de ces fonctions ou je travaillerais avec les entités dans un état détaché. Cela signifie que vous devez charger la liste des clients à partir de la base de données et disposer du contexte après cela. Lorsque vous sauvegardez les modifications - et maintenant, peu importe si toutes les modifications ou uniquement les modifications d'un seul client - vous pouvez créer un nouveau contexte, tirez l'entité/les entités d'origine de la base de données et mettez à jour avec les propriétés modifiées. Mais travailler avec des entités attachées ou détachées - ou bien avoir un contexte EF vivant par vue/forme ou créer un seul contexte de courte durée par opération CRUD - est une décision de conception importante à mon avis. Généralement, la possibilité d'avoir vos entités attachées à un contexte pendant la durée de vie d'une vue/d'un formulaire existe pour faciliter votre vie de programmeur, car elle vous offre des fonctionnalités telles que le chargement paresseux et le suivi des changements. Donc, vous pourriez penser à deux fois si vous voulez abandonner.

Pour reconnaître si un objet client a été modifié ou non, le contexte EF peut être utile car il suit l'état d'un objet.Vous pouvez par exemple interroger ObjectStateManager pour un client et vérifier s'il est dans un état "Modifié". Mais pour avoir cette option, vous devrez travailler avec des entités attachées comme expliqué ci-dessus. Puisque vous ne pouvez pas enregistrer (ou annuler) les modifications d'un seul objet, il est douteux que cela ait du sens de montrer à l'utilisateur que le client 1 et le client 3 ont changé. (Je montrerais probablement seulement "quelques clients ont changé".)

Si vous travaillez avec des entités détachées vous devez gérer à la main quels clients ont changé ou pas en mettant en application une sorte de logique de "drapeau sale". Voici un fil à ce sujet:

Different ways to implement 'dirty'-flag functionality