DesignPatterns: Что лучше всего использовать для пользовательского интерфейса в стиле мастера?

Question

Я реализую пользовательский интерфейс в стиле мастера. Когда пользователь проходит через мастер, нажимая «Далее», в зависимости от выбора, который он выбрал на каждом экране, ему придется пройти через определенный набор экранов мастера.

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

Могу ли я использовать связанный список? « шаблон проектирования команд »? Что вы рекомендуете?

Другими словами: где / Как вы абстрагируете / инкапсулируете логику определения следующего шага в мастере на основе того, что пользователь выбрал на конкретном шаге мастера?

Answer 1

Шаблон " State " может иметь смысл, если вы хотите разрешить пользователю перемещаться вперед и назад по мастеру.

Шаблон рабочего процесса также может иметь смысл. Может быть, исследовать с помощью Windows Workflow Foundation.

Answer 2

Мне нравится быть проще. Я устанавливаю значение для объекта, который я строю, с номером шага, поэтому, если я создаю страховой полис, у меня будет свойство в полисе, которое указывает, на каком шаге он находится. Затем у меня есть единственный метод - маршрутизатор, который просматривает политику и определяет, куда ее отправлять дальше. Вы можете встроить дополнительную логику в маршрутизатор, чтобы пропустить шаги, или вы можете поместить логику в каждый метод шага и перенаправить обратно к маршрутизатору. способ.

Answer 3

Другими словами: где / Как вы абстрагируете / инкапсулируете логику определения следующего шага в мастере на основе того, что пользователь выбрал на конкретном шаге мастера?

Один из способов сделать это - смоделировать классы Wizard, Step и Product. Может быть, что-то вроде этого?

public class Wizard
{
  public Step forward() {//...}

  public Step backward() {//...}

  public Step current() {//...}

  public Product getProduct() {//...}
}

public class Step
{
  public String name() {//...}

  public void commit(Product product) {//...}

  public void rollback(Product product) {//...}
}

public class Product
{
  //...
}

Цель мастера - создать продукт (автомобиль, компьютер, отдых и т. Д.).

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

Шаг будет экземпляром шаблона команды с возможностью отмены / повтора.

Answer 4

Я должен согласиться с Бо.

На самом деле, если вам нужен сложный набор правил для логики навигации, то у вас есть мастер с графическим интерфейсом, а не мастер под колпаком.

Если то, что вы пытаетесь построить, на самом деле волшебник, то каждый экран должен отображать максимум 2-3 разных экрана (IMO). Это можно легко сохранить в очень простую структуру (база данных, статический файл конфигурации).