Если вы примените здесь некоторую DDD-логику, которая дополняет букву «M» в MVC, состояние пользовательского интерфейса (процесс регистрации) принадлежит прикладному уровню, который может напрямую взаимодействовать с уровнями домена и инфраструктуры (четыре уровня: пользовательский интерфейс) Приложение, домен и инфраструктура). Концепция DDD заставляет вас «задуматься» о том, как сначала решить решение в коде. Давайте пройдем через это ...
Это индикатор прогресса
Состояние, которое вы хотите сохранить, - это шаг или ход регистрации. Итак, мой первый шаг - документировать прогресс или «шаги». Например, Шаг 1: Получить имя пользователя / пароль, Шаг 2: Получить электронную почту. В этом случае я бы применил логику, чтобы «переместить» модель на следующий шаг. Скорее всего, с помощью метода NextStep () в RegistrationService (RegistrationService.NextStep ()).
Ах, но это относится к слою приложения
Я бы создал службу на уровне приложений под названием RegistrationService. Я бы разместил здесь метод NextStep (). Но помните, что домен не будет содержать состояние модели здесь. В этом случае вы бы хотели сфокусировать состояние на прикладном уровне. Таким образом, в этом случае NextStep () будет воздействовать не на объект модели (поскольку он не входит в сферу ответственности домена), а на пользовательский интерфейс. Итак, вам нужно что-то, чтобы сохранить состояние процесса регистрации.
Отойдите от модели предметной области, как насчет ViewModel?
Итак, теперь мы знаем, что должны сохранять состояние чего-либо в пользовательском интерфейсе. MVC допускает концепцию под названием ViewModels (в ASP.NET MVC не уверен, как это называется в RoR). Модель представления представляет модель, которая будет отображаться представлением и / или частичными представлениями.
ViewModel будет отличным местом для сохранения состояния этого объекта. Давайте назовем его RegistrationProgressViewModel () и добавим к нему метод NextStep (). Это, конечно, означает, что прикладному уровню придется сохранять местоположение RegistrationProgressViewModel, а уровень APplication изменяет его внутреннее содержимое на основе действий NextStep. если это сложно, вы можете создать RegistrationProgressService () на уровне приложения и поместить в него NextStep (), чтобы абстрагировать вашу логику.
Как передать ViewModel?
Последняя часть - как отследить состояние этого объекта. Поскольку веб-приложения не имеют состояния, вы должны сохранять контроль другими способами, а не приложением. В этом случае я хотел бы вернуться к: 1) сериализации ViewModel клиенту и разрешению клиенту передавать его назад и вперед, или 2) сохранять копию ViewModel на стороне сервера и передавать некоторый тип идентификатора назад и вперед клиенту и обратно.
Это хороший пример для размышления, так как я сам еще этого не делал. Для # 2 наиболее безопасный и застрахованный способ сохранения состояния этой ViewModel - это сохранение его на уровне инфраструктуры (да, уровень APp может напрямую связываться с уровнем инфраструктуры). Мне кажется, это много работы, потому что что-то, что может исчезнуть, и у меня будет частичная регистрация в моей БД.
Но, # 2 будет хранить личную информацию пользователя (имя пользователя, пароль, адрес электронной почты, CC # и т. Д.) На стороне сервера и не передавать ее туда и обратно.
Наконец-то ответ!
Итак, пройдя через это, мы придумали:
- Создайте RegistrationProgressViewModel () на прикладном уровне.
- Создайте RegistrationProgressService () с помощью метода NextStep (ViewModel vm) на уровне приложений.
- Когда NextStep () выполняется, сохраните ViewModel в базе данных через слой инфраструктуры.
Таким образом, вам никогда не придется отслеживать, что такое «step? Id = 2» в самом View или самом пользовательском интерфейсе, так как ViewModel обновляется и обновляется (Authenticated, Verified, persisted to DB) по мере продвижения вперед.
Итак, ваша следующая задача - «двигаться вперед» в пользовательском интерфейсе. Это легко сделать с 1 контроллером, используя шаг или именованные шаги.
Я прошу прощения, но я пишу код C # ниже, так как это мой язык.
public class RegistrationController : Controller
{
// http://domain.com/register
public ActionResult Index()
{
return View(new RegistrationProgressViewModel);
}
// http://domain.com/register
// And this posts back to itself. Note the setting
// of "CurrentStep" property on the model below.
//
public ActionResult Index(
RegistrationProgressViewModel model)
{
// The logic in NextStep() here checks the
// business rules around the ViewModel, verifies its
// authenticity, if valid it increases the
// ViewModel's "CurrentStep", and finally persists
// the viewmodel to the DB through the Infrastructure
// layer.
//
RegistrationProgressService.NextStep(model);
switch (model.CurrentStep)
{
case 2:
// wire up the View for Step2 here.
...
return View(model);
case 3:
// wire up the View for Step3 here.
...
return View(model);
case 4:
// wire up the View for Step4 here.
...
return View(model);
default:
// return to first page
...
return View(model);
}
}
}
Вы заметите, что это абстрагирует «бизнес-логику» проверки внутреннего состояния модели в метод RegistrationProcessService.NextStep ().
Хорошее упражнение. :)
В конце концов, ваш «RESTful» url - это приятный и чистый POST для: / register, который ожидает ViewModel с конкретными заполненными свойствами. Если ViewModel недействителен, / register не переходит к следующему шагу.