ASP.NET MVC сохраняющиеся данные на нескольких шагах мастера с использованием таблиц базы данных

Question

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

В данный момент мы используем сеанс, чтобы сохранить много данных на нескольких шагах/видах мастера. Мы сталкиваемся с проблемой, и мы подозреваем, что время ожидания сеанса виновата. По этой причине мы решили заменить сеансы таблицами базы данных.

До сих пор мы установили, что нам нужно следующее:

• Когда пользователь нажимает на первой странице генерируется уникальный идентификатор/маркер (возможно базы данных первичного ключа), который будет определять, где данные хранится в течение рабочего процесса. Этот идентификатор/токен сохраняется с использованием URL-адреса , если это вообще возможно, так что нам не нужно выполнять сеансы.

• Отдельные таблицы для каждого вида/шага мастера. Мы реализовали логику в каждом действии, которое проверили объекты шага мастера, сохраненные в сеансе, чтобы гарантировать, что пользователь не сможет пропустить шаги в рабочем процессе. Реализация аналогичного тестирования с сохранением данных базы данных будет проще, если данные разделены на разные таблицы, а не на одну таблицу.

• Сохранение метки времени истечения срока годности где-то в записи, связанной с предоставленным идентификатором/токеном, для имитации тайм-аутов сеанса, например, когда обработки отправили форму, если текущее время даты больше, чем сохраненная отметка даты и времени отклонить запрос

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

Мы просто с трудом выяснить, как реализовать это в коде , Мы столкнулись с http://www.4guysfromrolla.com/webtech/041600-2.shtml, который был несколько полезен, но на самом деле не объяснил, как реализовать его в ASP.NET MVC-контроллере.

Мы предоставили фрагмент кода ниже, чтобы обеспечить некоторое понимание того, как мы в настоящее время деяния вещи, используя сессию:

контроллера

[HttpGet] 
public ActionResult StepOne() { 
    StepOneViewModel stepOneModel; 
    WizardViewModel wizard = (WizardViewModel)Session["Wizard"]; 

    if(wizard == null || wizard.StepOne == null) 
     stepOneModel = new StepOneViewModel(); 

    else 
     stepOneModel = wizard.StepOne 

    return View(); 
} 

[HttpPost] 
public ActionResult StepOne() 
{ 
    //validate and store data into wizard session object 
} 

public ActionResult StepTwo() 
{ 
    StepTwoViewModel stepTwoModel; 
    WizardViewModel wizard = (WizardViewModel)Session["Wizard"]; 

    if(wizard == null || wizard.StepOne == null) 
     return RedirectToAction("StepOne"); 

    if(wizard.StepTwo == null) 
     stepTwoModel = new StepTwoViewModel(); 

    else 
     stepTwoModel = wizard.StepTwo; 

    Session["Wizard"] = wizard; 

    return View(); 
} 

Мастер Модель

public WizardViewModel 
{ 
    public StepOne { get; set; } 
    public StepTwo { get; set;} 
} 

Каков наилучший способ реализации этого подхода? Как мы создаем/отслеживаем этот уникальный токен, который определяет, откуда извлекаются данные? Как мы тестируем, что пользователи выполнили предыдущие шаги и не пробовали пропустить? Любой код контроллера/мысли о том, как мы можем реализовать этот подход, оцениваются.

Answer 1

Вот как мы реализовали аналогичную модель в прошлом. Я предполагаю, что здесь, что пользователи не зарегистрированы в системе (если они, то это немного легче)

1. Первый шаг на мастере, чтобы собрать пользователей электронной почты.

2. Мы генерируем уникальный токен для этой сессии и вставляем его в URL-адрес и отправляем по электронной почте пользователю.Это может быть использовано пользователем для возврата в любое время и завершения рабочего процесса. Вам нужно сделать маркер достаточно большим, чтобы люди не могли просто угадать случайные токены.

Примечание: Мы фактически генерируем идентификатор токена, который мы используем внутри, чтобы отобразить процесс рабочего процесса. Мы также создаем хэш, который встроен в URL-адрес и отправляется пользователю.

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

4. Токены обычно очищаются, то есть токены старше 2 недель удаляются. URL-адрес, по которому пользователь был отправлен по электронной почте, по-прежнему работает, но переносит его на новый рабочий процесс, а токен используется повторно для нового сеанса.

5. И наконец, если рабочий процесс завершен, мы можем удалить токен из системы.

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