Как сохранить введенные значения в форме в ASP.NET MVC, если пользователь не прошел проверку сервера?

Question

У меня есть приложение ASP.NET MVC, которое должно быть удобным для пользователя, и MVC не предлагает ViewState.Моя проблема заключается в том, что если пользователь не проходит проверку сервера, то я не хочу, чтобы он снова вводил все значения.

Как решить эту проблему в ASP.NET MVC?

Answer 1

Но если честно, если пользователь не проходит проверку сервера, то я не хочу им нужно снова ввести все значения. Я не очень понимаю Каково решение MVC для этой проблемы применимости?

На самом деле картина довольно проста. Вы проектируете модель вида:

public class MyViewModel
{
    [Required]
    public string Foo { get; set; }
    public string Bar { get; set; }
    public int Baz { get; set; }
}

затем контроллер:

public class HomeController: Controller
{
    public ActionResult Index()
    {
        return View(new MyViewModel());
    }

    [HttpPost]
    public ActionResult Index(MyViewModel model)
    {
        if (!ModelState.IsValid)
        {
            // validation failed => redisplay the view so that
            // the user can fix his errors
            return View(model);
        }

        // TODO: A this stage the model passed validation =>
        // do some processing here and redirect

        return RedirectToAction("Success");
    }
}

и, наконец, соответствующий вид:

@model MyViewModel

@Html.ValidationSummary(false)

@using (Html.BeginForm())
{
    <div>
        @Html.LabelFor(x => x.Foo)
        @Html.EditorFor(x => x.Foo)
    </div>
    <div>
        @Html.LabelFor(x => x.Bar)
        @Html.EditorFor(x => x.Bar)
    </div>
    <div>
        @Html.LabelFor(x => x.Baz)
        @Html.EditorFor(x => x.Baz)
    </div>

    <p><button type="submit">OK</button></p>
}

Теперь, когда пользователь переходит на /home/index, ему предоставляется форма для заполнения, в которой он вводит некоторую информацию в соответствующие поля ввода и отправляет форму. Связыватель модели по умолчанию включается и связывает модель представления из значений запроса в соответствующем действии POST. Если проверка не пройдена, состояние модели помечается как недопустимое, и теперь вы можете снова отобразить то же представление. Поскольку вся информация была размещена в состоянии модели, помощники HTML, которые использовались для генерации полей ввода, смогут получать значения и сохранять их на этапе обратной передачи.

Answer 2

что за суета связана с отсутствием поддержки состояния в веб-приложении?

Это сложная область.Например, одним из недостатков использования сеанса для управления состоянием является то, что если это сеанс RW, то только один поток за раз может взаимодействовать с ним.Это становится проблемой, если у вас есть несколько потоков в одном сеансе (например, для нескольких вызовов ajax с одной и той же страницы, выполняемых параллельно).Включение сеанса означает, что эти потоки блокируются при взаимодействии с сеансом RW, и, следовательно, каждому последующему потоку требуется больше времени для выполнения.

Кроме того, для веб-приложений, которые должны быть отказоустойчивыми, если вы используетеНесколько узлов в качестве фермы, затем вам нужно использовать поставщика поддержки общего состояния сеанса (для сервера SQL или распределенного кэша), чтобы гарантировать, что на каком бы сервере пользователь не работал, он выглядит как одно и то же состояние.Это влечет за собой снижение производительности.

Но, если честно, если пользователь не пройдет проверку сервера, то я не хочу, чтобы ему приходилось вводить все значения снова

Для этой проблемыЧтобы избежать полной обратной передачи и обеспечить сохранение изменчивых данных пользователя, введенных на странице, даже если существует проблема с проверкой, вам следует попробовать выполнить проверку на стороне клиента.Это не моя область знаний, но вам стоит взглянуть на ненавязчивая проверка на стороне клиента .Его реализация требует больших усилий, но оно того стоит из соображений производительности и удобства использования.

Что касается достоинств / недостатков viewstate в целом, я думаю, что причина, по которой традиционная мудрость отходит от этого, заключается в том, что (какЯ уверен, что вы в курсе), viewstate несет много потенциальных ловушек, включая потенциально чрезмерно большие состояния, передаваемые в браузер и из него (и необходимость десериализации на стороне сервера), а также приводящие к нечистоте HTML отображается на клиенте.ИМХО самое лучшее в MVC - это чистота отображаемого HTML-кода.

Для простого, монолитного веб-приложения, которое не должно быть супер отказоустойчивым, я не вижу проблем с использованием ASP.NET + Viewstate для управления сессиями.Все зависит от того, чего должен достичь ваш сайт.Я уверен, что другие будут иметь свои мысли.Надеюсь, это полезно для вас!