Structure de suivi des changements

Question

Nous cherchons à mettre en œuvre un verrouillage optimiste dans notre application WCF/WPF. Jusqu'à présent, la meilleure façon de procéder que j'ai trouvée est d'implémenter un Optimistic générique qui stockera une copie de l'original et des modifications (il stockera donc deux copies : l'original et la modification) de tout objet de valeur qui peut être modifié. Est-ce la meilleure façon de procéder ?

Par exemple, un UserVO sera enveloppé par le générique comme un Optimistic. Lorsqu'une modification est apportée à l'Optimistic, la modification sera apportée à la copie modifiée stockée dans l'Optimistic tandis que l'original également stocké dans l'Optimistic restera intact. Le principal problème semble être que cela utilisera deux fois plus d'espace et donc de bande passante.

Merci

EDIT La solution doit être indépendante de la base de données, et il serait utile de pouvoir spécifier une politique de résolution des conflits par objet de valeur. (par exemple, un objet utilisateur pourrait essayer de fusionner si les lignes mises à jour n'ont pas été modifiées, mais un objet transactionnel nécessiterait toujours l'intervention de l'utilisateur).

Answer 1

Si vous utilisez le serveur SQL, vous pouvez utiliser une colonne d'horodatage. La colonne d'horodatage est modifiée à chaque fois qu'une ligne est modifiée. Essentiellement, lorsque vous mettez à jour la base de données, vous pouvez vérifier si la colonne d'horodatage est la même que lorsque le client a reçu les données pour la première fois, si c'est le cas, personne n'a modifié les données.

Editar

Si vous voulez minimiser la bande passante, vous pouvez émuler le concept d'horodatage en ajoutant un numéro de version à chaque objet. Ainsi, par exemple :

1. Le client 1 demande un objet, le serveur renvoie l'objet V1
2. Le client 2 demande un objet, le serveur renvoie l'objet v2
3. Le client 1 modifie l'objet et le renvoie au serveur en tant que V1.
4. Le serveur compare la version et voit que v1=v1, ce qui lui permet de valider le changement.
5. Le serveur incrémente la version de l'objet, qui est maintenant v2.
6. Le client 2 modifie l'objet et le renvoie au serveur en tant que v1.
7. Le serveur compare la version et voit que v1!=v2 et exécute donc la politique que vous avez définie.

Pour configurer votre politique, vous pouvez définir dans une configuration un objet spécifique qui traitera les échecs de la politique en fonction du type d'objet racine. Vous pourriez créer une interface IOptomisticCheckFailurePolicy, et vous pourriez probablement utiliser une des bibliothèques DI comme structure map pour créer l'objet quand vous en avez besoin (bien que vous puissiez tout aussi bien le charger en utilisant la réflexion).

Answer 2

L'une des façons de mettre en œuvre une logique de verrouillage optimiste consiste à la baser sur l'horodatage de la dernière modification d'une ligne. La mise à jour se présente donc comme suit :

UPDATE .... WHERE id = x AND last_updated = t

x : numéro d'identification de l'enregistrement t : date de la dernière mise à jour de la ligne lorsqu'elle a été chargée à partir de la base de données (c'est-à-dire avant les modifications).

Notez que l'un des champs qui doit être mis à jour directement ou indirectement est l'horodatage qui doit être fixé à now (ou UtcNow).

Ainsi, la mise à jour échouera si l'enregistrement a été modifié en arrière-plan. Une fois que la mise à jour a échoué, vous pouvez lancer d'autres requêtes pour détecter la cause de l'échec. Par exemple,

1. L'enregistrement a été supprimé.
2. L'enregistrement a été modifié.

Cette approche simple fournit un verrouillage optimiste au niveau de la ligne, elle n'est pas basée sur les colonnes et n'a pas de résolution de conflit.

Answer 3

Avez-vous regardé le Cadre Microsoft Sync ?