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

Question

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

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

Могу ли я использовать связанный список? "Command Design Pattern"? Что вы порекомендуете?

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

Answer 1

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

Один из способов сделать это - это моделирование классов 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 под управлением пользовательского интерфейса, который был бы Директором и рассказывать Wizard, когда и в каком направлении сделать переход. Мастер должен решить, что на самом деле следующий шаг. Могут поддерживаться несколько точек ветвления, но эта реализация будет скрыта внутри Wizard.

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

Answer 2

Образец «State» может иметь смысл, если вы хотите разрешить пользователю перемещаться вперед и назад через мастер.

Образец рабочего процесса может также иметь смысл. Возможно, расследуйте использование основы Windows Workflow.

Answer 3

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

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

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

Answer 4

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