Snapshot Histoire Avec Entity Framework

Question

J'ai regardé quelques crochets d'audit avec Entity Framework. Beaucoup d'entre eux montrent anciens / nouvelles comparaisons de valeur. Cela fait beaucoup pour une piste de vérification, mais je suis à la recherche d'objets instantané.

Par exemple ... Disons que j'ai une application qui gère les produits. Un produit possède de multiples attributs et d'autres objets associés. Disons que je change un objet 10 fois. Disons aussi que c'est important que je peux voir les écrans de ces changements d'objet (et non une piste de vérification, mais ce que l'écran avait l'air vraiment comme dans un format de lecture uniquement). Ce que je suis intéressé est d'être capable de récupérer l'objet produit d'origine EF (avec toutes les données associées) pour l'ensemble 10 de ces changements (selon que je veux voir) et l'utiliser pour se lier à mon écran.

Si j'utilise SQL Server, quel type dois-je utiliser pour l'objet sérialisé de nos jours (XML, blob, etc.)? Est-il judicieux de le faire?

Answer 1

Voyons voir. Vous avez besoin de prendre un graphe d'objet et sérialisation dans la base de données dans un format qui vous permettra de matérialiser plus tard. Je pense qu'il existe des outils qui font exactement cela. L'un d'eux, il me semble, est le Entity Framework.

Qu'est-ce que vous voulez faire est une chose très commune. Considérons un moteur de wiki. Le wiki doit avoir une révision de la pointe que tout le monde voit, plus les révisions arrière de chaque document. Le wiki doit également être en mesure d'afficher une révision en arrière de la même manière qu'une révision de pointe est affichée. Par conséquent, le même format de stockage doit être utilisé pour les deux.

Je propose que vous permettez à tous vos types d'entités à versionné. Lorsque vous modifiez un type d'entité, vous modifier la dernière révision et stocker une révision en arrière contenant les valeurs précédentes. (La raison pour laquelle vous modifiez la dernière révision au lieu d'insérer une nouvelle astuce est parce que d'autres objets qui ne sont pas actuellement matérialisées dans un ObjectContext, peuvent contenir des liens vers la pointe que vous souhaitez conserver des liens vers la pointe, plutôt que des liens vers la révision en arrière.)

Si nécessaire, vous pouvez partitionner vos tables SQL Server afin que les révisions de retour sont stockés dans un groupe de fichiers différent. Cela vous permettra de sauvegarder les révisions et les révisions pointe arrière séparément.

Answer 2

Vous devez d'abord ajouter un ensemble de propriétés à vos tables:

• Version -. Heure de dernière modification (peut également être au lieu de l'auto-incrémentation compteur temps)
• lastModifiedBy -. Référence à l'utilisateur qui a fait la dernière modification (si vous stockez que)

Ensuite, vous avez plusieurs options sur la façon de stocker l'historique des versions. Vous pouvez

1. Créer une nouvelle table pour chacune des tables principales que vous voulez stocker l'historique pour. Que les tables d'histoire auront tous les mêmes champs que la table principale, mais les clés primaires et étrangères ne seront pas appliquées. Pour chaque clé étrangère stocke également la version d'entrée référencée à la version de temps a été créé.

2. ou vous pouvez sérialiser tout intéressant au sujet de votre entité et stocker tout ce que blobs un numéro de série pour toutes les entités que vous voulez à la version dans une table d'histoire mondiale (je préfère la première approche).

Comment remplir vos tables d'historique? Via la mise à jour et supprimer les déclencheurs.

• Dans la mise à jour déclencheur pour votre entité - copier toutes les valeurs antérieures à la table de l'histoire. Pour chaque clé étrangère - copier également la version actuelle de l'entité référencée
.
• Dans déclencheur de suppression - faire essentiellement la même
.

Notez que plus et des systèmes plus modernes ne supprime pas vraiment quoi que ce soit. Ils ont juste marque choses supprimées. Si vous voulez suivre ce modèle (qui a plusieurs avantages) -. Au lieu de supprimer ajouter l'indicateur IsDeleted à vos entités (bien sûr, vous avez alors de filtrer les entités supprimées partout)

Comment voyez-vous votre histoire? Il suffit d'utiliser la table d'historique, car il a toutes les mêmes propriétés que la table principale - ne devrait pas être un problème. Mais - lors de l'expansion des clés étrangères - veiller à ce que l'entité référencée version est la même chose que vous stockez dans votre table d'historique. Si ce n'est pas - vous devez aller à la table Histoire de valeurs que l'entité et de saisir référence là-bas. De cette façon, vous aurez toujours un aperçu de la façon dont l'entité ressemblait à ce moment, y compris toutes les références.

En plus de tous les ci-dessus - vous pouvez également restaurer l'état de votre entité à une version antérieure.

Notez que cette mise en œuvre, bien que facile, peut consommer un peu d'espace, car il stocke instantané , non seulement toute modification. Si vous souhaitez stocker seulement des changements - dans déclencheur de mise à jour, vous pouvez détecter quels champs ont été modifiés, et les sérialiser magasin dans le tableau de l'histoire mondiale. De cette façon, vous pouvez au moins montrer dans l'interface utilisateur ce qui a été changé et par qui (bien que vous pourriez avoir des ennuis à revenir à une version précédente).

Answer 3

Sur un projet, je récemment construit, nous avons utilisé nous branché à la méthode SaveChanges dans la classe DbContext. Cela nous a donné accès à une instance de la classe ChangeTracker. L'appel ChangeTracker.Entries() vous donne accès à une liste de DbEntityEntry. DbEntityEntry a les propriétés et méthodes intéressantes suivantes:

• State - est l'objet nouvellement créé, modifié ou en cours de suppression
• Entity - une copie de l'objet tel qu'il est
• CurrentValues - une énumération des valeur modifiée
• OriginalValues - une énumération des valeurs d'origine

Nous avons créé un ensemble de Poços pour les jeux de changement et les changements que nous avons pu accéder ensuite par EF. Cela a permis à nos utilisateurs de visualiser les changements au niveau du terrain ainsi que les dates et les utilisateurs responsables.