Comment résoudre les mises à jour concurrentielles optimistes dans les applications C# .NET N-tier?

Question

Hy tout le monde.

Dans C# .net VS 2008 Je suis en train de développer une solution de gestion de la relation client N-tier et lorsque c'est fait, je veux le partager.

L'architecture est basée sur:

données Couche d'accès, Entity Framework, Bussines couche logique, WCF et enfin la couche de présentation (gagner des formes).

Quelque part j'avais lu, que plus de 2 couches de niveau sont problématiques, en raison des mises à jour de simultanéité optimiste (plusieurs transactions de client avec les mêmes données).

In max. Solutions de couche à deux niveaux Cela ne devrait pas poser de problème à cause des contrôles (comme datagridview) qui résolvent ce problème par eux-mêmes, donc je me demande s'il ne vaut pas mieux travailler avec des couches à deux niveaux et éviter la concurrence optimiste problème?

En fait, je veux faire une solution de couche N-tier pour les projets énormes et non à 2 niveaux. Je ne sais pas comment résoudre les problèmes de concurrence comme celui-ci et j'espère obtenir de l'aide ici même.

Certes, il devrait y avoir quelques mécanismes pour résoudre ce problème ... peut-être des suggestions, des exemples, etc.?

En vous remerciant par anticipation.

Meilleures salutations, Jooj

Answer 1

Ce n'est pas vraiment une question de nombre de tiers. La question est de savoir comment votre logique d'accès aux données gère la concurrence. Le traitement de la simultanéité devrait se faire dans n'importe quel niveau qui gère votre accès aux données, quel que soit le nombre de niveaux que vous avez. Mais je comprends d'où vous venez car les contrôles .NET et les composants peuvent masquer cette fonctionnalité et réduire le nombre de niveaux nécessaires.

Il existe deux méthodes courantes de résolution d'accès concurrent optimiste. Le premier est l'utilisation d'un horodatage sur les lignes pour déterminer si la version que l'utilisateur regardait lorsqu'il a commencé son édition a été modifiée au moment où il a validé son édition.Gardez à l'esprit qu'il ne s'agit pas nécessairement d'un type de données de base de données Timestamp correct. Différents systèmes utiliseront différents types de données, chacun ayant ses propres avantages et inconvénients. C'est l'approche la plus simple et fonctionne bien avec la plupart des bases de données bien conçues.

La deuxième approche commune consiste, lors de la validation des modifications, à identifier la ligne en question non seulement par l'ID, mais également par toutes les valeurs d'origine des zones modifiées par l'utilisateur. Si les valeurs d'origine des champs et ID ne correspondent pas à l'enregistrement en cours de modification, vous savez qu'au moins un de ces champs a été modifié par un autre utilisateur. Cette option a l'avantage que même si deux utilisateurs éditent le même enregistrement, tant qu'ils ne changent pas les mêmes champs, la validation fonctionne. L'inconvénient est qu'il existe un travail supplémentaire possible pour garantir que les données dans l'enregistrement de la base de données sont dans un état cohérent en ce qui concerne les règles métier.

Here's une explication décente de la façon d'implémenter une simultanéité optimiste simple dans EF.

Answer 2

Nous utilisons une fusion manuelle de combinaison (détermination des ensembles et des collisions changement) et le dernier homme gagne en fonction des besoins de données. Si les modifications apportées aux données se répercutent sur le même champ que la valeur d'origine commune, les exceptions de type fusion sont levées et les clients gèrent cela.

Answer 3

Quelques choses me viennent à l'esprit:

1) Si vous utilisez EF sûrement vous don'y avez accès aux données couche ?! Voulez-vous dire la base de données elle-même?

2) La question avec les niveaux est à la fois physique et logique. Voulez-vous dire physique ou logique?

3) Dans une application à plusieurs niveaux, il y a ce problème avec la simultanéité. Même dans le client-serveur, les gens pourraient ouvrir un formulaire, aller ailleurs et revenir et enregistrer alors que les données ont été changées par tout le monde. Vous pouvez utiliser un horodatage pour vérifier lors de l'enregistrement en vous assurant que votre dernière mise à jour a eu lieu lorsque vous avez eu les données.

4) Ne pensez pas trop à des niveaux inférieurs ou supérieurs. Il suffit de mettre en œuvre la fonctionnalité aussi simple que possible et avec le nombre minimum de couches.