Постоянство данных на сервере ASP.NET
Я не совсем уверен, как именно следует сформулировать вопрос, поэтому, пожалуйста, наберитесь терпения, если я задам не то, что нужно.
Я пишу приложение ASP.NET, используя VB в качестве кода языка. У меня есть класс доступа к данным, который подключается к БД для выполнения запроса (конечно, параметризованный) и другой класс для выполнения задач проверки - я обращаюсь к этому классу со своей страницы aspx.
Я хотел бы иметь возможность хранить данные на стороне сервера и ждать, пока пользователь выберет один из нескольких вариантов в зависимости от достоверности данных. Но разве мое понимание полностью отключено, наличие постоянных объектов данных на сервере создаст проблемы при подключении нескольких пользователей?
Моя конечная цель состоит в том, чтобы после проверки данных конечный пользователь не мог их изменить. В настоящее время я проверяю данные, но мне все еще приходится извлекать их из веб-формы ПОСЛЕ того, как пользователь говорит "ОК", что, очевидно, оставляет открытой возможность ввода неверных данных либо случайно (маловероятно), либо специально (также маловероятно для использования, но я бы предпочел не рисковать).
Так я полностью в моем понимании? Если да, может ли кто-нибудь указать мне на ресурс, который предоставляет некоторые инструкции по хранению постоянных данных на сервере, или предоставляет инструкции?
Спасибо!
Конкретный пример:
Недавно мы наняли инспектора Гаджета для вставки данных для инспекторов по знакам, которые осматривают дорожные знаки, чтобы удостовериться, что ни один из них не был поврежден или похищен жевательной резинкой, обычно преуспевающими членами городского совета молодежи.
Если Гаджет сможет доказать свою храбрость, он может быть повышен до фактического осмотра знака. На данный момент его единственная работа состоит в том, чтобы заходить на этот интранет-сайт и вводить информацию о самых последних проверках. Район, округ, № маршрута, участок дороги и даты, когда знак был установлен и проверен.
Конечно, любой из нас, кто был жив в конце 80-х, знаком с неумелостью Гаджетов. Таким образом, сайт настолько же надежен, насколько мы можем сделать это. Район / округ / маршрут заполнены в раскрывающемся списке, ему нужно только вручную ввести начало и конец раздела и даты. Иногда он шарит мышью и в конце меняет местами начало и конец раздела, черт! Таким образом, текст становится красным, чтобы предупредить его об ошибке. К сожалению, он решил носить свои анти-красные солнцезащитные очки сегодня, которые превращают все красные цвета в черный. Ну, после попытки предоставить данные, он показывает сообщение об ошибке, сообщающее ему, где и что он должен исправить. К сожалению, он ткнул пальцем в клавиатуру и вместо 1,333 набрал 13,37 (миль)- а длина дороги всего 10 миль! Что ж, теперь появляется сообщение (модальный div), в котором говорится, что реальный пробег дороги 0-10, и что его вход объединит три участка дороги. Затем ему дают три кнопки на выбор. Отмена, которая позволяет ему перейти и изменить свои данные, Constrain, которая преобразует 13,37 в 10, и Override, которая позволит ему вводить эти данные в любом случае.
"Yowza!" Гаджет воскликнул, и нажал кнопку отмены, чтобы вернуться и исправить свою ошибку. Что ж, следующий набор данных он ввел правильно, поэтому появилось подтверждающее сообщение, показывающее ему изменения, которые он собирался внести, и спрашивающее, можно ли продолжить. Ну, к сожалению, инспектор Гаджет опрокинул чашку с кофе, разбрасывая детрит по столу. В спешке очистить его, он нажал "ОК", но не раньше, чем его электромагнит Go-Go-Gadget случайно щелкнул несколько бит на своем компьютере, изменив графство в форме с ARKANSAS на AKRSANAS, черт!
Если бы данные были сохранены на сервере через кампус, и единственной передаваемой информацией было "ОК" или "Отмена", этого можно было бы избежать.
Конечно, я всегда могу проверить снова после "ОК", но это выглядит как хакерский обходной путь.
Во всяком случае, я надеюсь, что это проясняет!
2 ответа
Я думаю, что вы думаете об использовании кэша веб-сервера. В ASP.NET вы можете использовать Context.Cache для хранения данных на сервере. Как только один пользователь кэширует его, любой другой пользователь на сервере также может получить к нему доступ.
Поскольку данные кэшируются на сервере, вы хотите очищать кэш каждый раз, когда вызываете запрос на обновление в БД. Затем в следующий раз, когда вы загрузите данные, вы можете снова сохранить данные в кеше.
В вашем методе выбора проверьте, не является ли ваш Cache [ключ] нулевым. Если это так, загрузите данные из БД и сохраните их в Cache [ключ], прежде чем возвращать данные. Если он не нулевой, просто загрузите его из кеша, а не из БД.
Ключ, который вы используете, может содержать ваши параметры, поэтому вам не нужно фильтровать данные из кэша.... или ключ может быть просто универсальным, чтобы в нем сохранялись все ваши данные. Затем вы можете выполнить запрос LINQ для данных, чтобы отфильтровать по вашим параметрам
Я надеюсь, что это помогает.
Я думаю, что вы имеете в виду параллелизм. Проверьте ссылку, чтобы начать понимать ее, если это то, о чем вы спрашиваете. Вам, вероятно, придется сделать немного больше исследований в зависимости от вашей серверной части и вашей конкретной ситуации. Опять же, если это то, что вы ищете, вас может заинтересовать пессимистический параллелизм.
http://en.wikipedia.org/wiki/Concurrency_control
РЕДАКТИРОВАТЬ: После прочтения вашего примера.... кажется, что вы можете сделать следующее, удачи.
"заблокировать" запись, используя какой-то пессимистический образец параллелизма (в БД, поскольку именно там находятся данные), когда к нему обращается пользователь, вводящий данные. Это все равно что делать запись в БД только для чтения.
Когда пользователь нажимает "ОК", вам, вероятно, придется выполнить проверку с помощью кода asp.net, а если проверка пройдена, обновите базу данных и разблокируйте запись базы данных.
Если пользователь нажимает "Отмена", не обновляйте запись в БД, просто разблокируйте ее.
Если пользователь хочет форсировать ввод, просто обновите базу данных и разблокируйте запись базы данных.