1 контроллер : RegistrationController
6 методов действия :
- GET + POST для индекса (заполните основную информацию)
- GET + POST для пакета
- GET для спасибо
- GET для ошибки
Это грубый код, который заставит вас задуматься:
public class RegistrationController : Controller
{
public ActionResult Index()
{
RegistrationState model = RegistrationState.Init();
// just display the "Fill Basic Info" form
return View(model);
}
[HttpPost]
public ActionResult Index(RegistrationState data)
{
// process data and redirect to next step
this.TempData["RegState"] = data;
if (!this.ModelState.IsValid || data.State == State.Error)
{
// error should handle provided state and empty one as well
return RedirectToAction("Error");
}
return RedirectToAction("Package");
}
public ActionResult Package()
{
RegistrationState data = this.TempData["RegState"] as RegistrationState;
if (data == null)
{
return RedirectToAction("Error");
}
// get packages and display them
IList<Package> model = this.repository.GetPackages();
return View(new Tuple.Create(data, model));
}
[HttpPost]
public ActionResult Package(RegistrationState data)
{
// process data blah blah blah
}
// and so on and so forth
....
}
Как вы видите, вам все еще нужно написать некоторый код, связанный с MVC, чтобы действовать при изменении состояния.В моем примере все сделано в методах действия.Но фильтры действия также могут быть использованы.Если вы не можете придумать фильтр общего действия, который может обслуживать множество различных объектов состояния, то лучше просто написать код в методах действия.
Другой подход
Если вы знаете Asp.net MVC достаточно хорош, чтобы вы могли пойти дальше и написать конечный автомат ControllerFactory, который будет работать вместе с маршрутизацией в следующем смысле:
{StateObjectType}/{State}
ControllerFactory сможет анализировать данные представления в известном состоянии.тип объекта и передача выполнения к определенному действию.По гос.Это сделало бы его специальным конечным автоматом, подходящим для приложения MVC Asp.net.
Более важный вопрос, конечно, заключается в том, можете ли вы создать приложение целиком с этим шаблоном или есть только некоторые его части, которые должны работать какэтот.Конечно, вы можете объединить оба подхода и обеспечить соответствующую маршрутизацию для каждого.
Важные замечания
Вы должны быть очень осторожны при определении состояния ошибки, поскольку вводите недопустимое поледанные не должны приводить к состоянию ошибки, а скорее к ошибкам проверки данных, которые фактически отображаются в представлении рядом с полем с недопустимыми данными (то есть недопустимая дата, указанная как 13/13/1313)Ваше состояние ошибки должно использоваться только для фактической ошибки состояния объекта, которая не связана с пользовательским вводом.Что бы это могло быть за пределами моего воображения.
Как уже упоминалось в моем комментарии, вы должны посмотреть некоторые вступительные видеоролики Asp.net MVC, и вы увидите, как проверка работает в Asp.net MVC.Также довольно простые вещи.
Шаблон состояний такого рода не является чем-то, что обычный разработчик Asp.net MVC использовал бы, потому что он, скорее всего, усложнил бы код больше, чем принятие нормального подход.Проанализируйте, прежде чем решить.Asp.net MVC очень чистый код, поэтому добавление к нему дополнительной абстракции может привести к путанице.И ваша доменная модель (классы состояний), скорее всего, будет иметь гораздо более сложный код, чем простые POCO с аннотациями данных.
В вашем случае проверка данных также будет более сложной (при использовании с аннотациями данных), поскольку вы возражаетедолжны быть проверены в соответствии с его состоянием, которое может быть различным в разных штатах.Объекты POCO всегда проверяются одинаково.Это может означать, что мы можем использовать больше классов, но они меньше, проще и проще в обслуживании.