Съдържание
Работата с съвпадение В уеб приложенията това е една от темите, на които трябва да отделим малко качествено време, тъй като поради самия характер на приложението може да открием случаи, в които няколко потребители трябва да взаимодействат с един и същ елемент.Само по себе си е взаимодействие Това не е проблем, истинският проблем идва, когато след като промените или докоснете този елемент, е необходимо да го запишете в базата данни и след това двама или повече потребители искат да извършат действие върху един и същ елемент едновременно, именно там нашата логика трябва да дефинира поведение, за да знае какъв е правилният начин да се справим с това.
Както обяснихме в началото, съвпадение Това е, когато двама или повече участници работят върху елемент в нашето приложение, генерирайки действие срещу базата данни.
Дело за паралелностПроблеми могат да възникнат, когато промените са противоречиви, например: потребител А е запазил стойност, но потребителят В също е модифицирал по това време и е запазил различна стойност, в очите на потребителя А съдържанието му не е променено и в очите на потребител Б нямаше нищо, което да го спре да направи промяната си.
Този тип конфликти могат да потъмнят работата на нашето приложение в очите на потребителя, така че трябва да преценим дали областите, които имаме, ще си заслужават или не ще бъдат програмирани за едновременност.
Нека да видим някои видове едновременност, по този начин можем да разберем малко повече какъв вид действия можем да извършим в нашите приложения:
Песимистична едновременностТози подход предлага, че когато използваме базата данни, ние правим a превантивно блокиране на използвания регистър, с това избягваме, че множество потребители променят стойността едновременно, проблемът води до това, че в уеб средата не е възможно да се използва цялостно, тъй като няма състояния, които не знаем дали заключването е бил приложен или премахнат, докато не комуникираме със сървъра, генерирайки объркване и забавяне в използването.
Оптимистична избирателна активностТози друг подход вместо това прави нещо малко по -съвместимо с мрежата, когато се променя, преди да се запише в базата данни, той проверява дали данните не са били променени от момента на четене, за това правим сравнение на стойностите на записа и свързано поле, което носи времева отметка с дата, час и секунди за по -голяма точност.
ASP.NET MVC Той не поддържа песимистичния подход, затова трябва да работим с оптимистичния, за това трябва да предоставим на нашите структури полета за дата, за да запазим последния път, когато е бил променен, за да можем да знаем дали стойността е променена, след като получихме записа и преди да го запишем, с това можем да получим сигнал и по този начин да решим дали да презапишем тези стойности или не.
Нека видим малък пример за код как можем да потвърдим това:
В края на този урок вече знаем малко повече за едновременността в базите данни и как да решим проблема в ASP.NET MVC.
