ASP.NET MVC - Gelijktijdige databases

De afhandeling van de overeenstemming In webapplicaties is het een van de onderwerpen waaraan we wat quality time moeten besteden, omdat we vanwege de aard van de applicatie gevallen kunnen vinden waarin meerdere gebruikers met hetzelfde element moeten communiceren.
op zichzelf is interactie Het is geen probleem, het echte probleem komt wanneer na het wijzigen of aanraken van dit element het nodig is om het op te slaan in de database en dan twee of meer gebruikers tegelijkertijd een actie willen uitvoeren op hetzelfde element, dat is waar onze logica moet een gedrag definiëren om te weten wat de juiste manier is om hiermee om te gaan.
Zoals we aan het begin hebben uitgelegd, is de overeenstemming Het is wanneer twee of meer actoren aan een element in onze applicatie werken en een actie tegen de database genereren.
GelijktijdigheidsgevalEr kunnen problemen ontstaan ​​wanneer de wijzigingen tegenstrijdig zijn, bijvoorbeeld: gebruiker A heeft een waarde opgeslagen, maar gebruiker B was op dat moment ook aan het wijzigen en heeft een andere waarde opgeslagen, in de ogen van gebruiker A is de inhoud niet gewijzigd en in de ogen van de gebruiker B was er niets dat hem ervan weerhield zijn wijziging door te voeren.
Dit soort conflicten kan de prestaties van onze applicatie in de ogen van de gebruiker aantasten, dus we moeten evalueren of de gebieden die we hebben de moeite waard zijn om te programmeren voor de gelijktijdigheid.
Laten we eens kijken soorten gelijktijdigheid, op deze manier kunnen we iets meer begrijpen wat voor soort acties we in onze applicaties kunnen uitvoeren:
Pessimistische gelijktijdigheidDeze benadering stelt voor dat we bij het gebruik van de database een preventieve blokkade van het register in gebruik, hiermee vermijden we dat meerdere gebruikers tegelijkertijd de waarde wijzigen, het probleem heeft tot gevolg dat het in de webomgeving niet mogelijk is om het grondig te gebruiken, omdat er geen toestanden zijn, weten we niet echt of het slot werd toegepast of verwijderd totdat we met de server communiceerden, wat verwarring en traagheid in het gebruik veroorzaakte.
Optimistische opkomstDeze andere benadering doet in plaats daarvan iets meer compatibel met het web, bij het wijzigen, voordat het in de database wordt opgeslagen, wordt gecontroleerd of de gegevens niet zijn gewijzigd vanaf het moment dat de lezing is uitgevoerd, hiervoor maken we een vergelijking van recordwaarden en een bijbehorend veld met een tijdstempel met datum, tijd en seconden voor grotere nauwkeurigheid.
ASP.NET MVC Het ondersteunt de pessimistische benadering niet, dus we moeten werken met de optimistische, hiervoor moeten we onze structuren voorzien van datumvelden om de laatste keer dat het is gewijzigd op te slaan, zodat we kunnen weten of de waarde is gewijzigd nadat we het record hebben verkregen en voordat we het opslaan, kunnen we hiermee een waarschuwing krijgen en zo beslissen of we die waarden al dan niet willen overschrijven.
Laten we een klein codevoorbeeld bekijken van hoe we dit kunnen valideren:

We merken dan dat we bij het maken van een wijziging in de database valideren of het veld is gewijzigd nadat we de lezing hebben gedaan, zo ja we maken een uitzondering, hiermee zullen we de bijbehorende acties kunnen ondernemen, we laten ook ruimte om te kunnen werken aan de verschillende uitzonderingen die kunnen worden gegenereerd.
Aan het einde van deze tutorial weten we al iets meer over concurrency in databases en hoe het probleem in te werken ASP.NET MVC.