Defining application flow in ASP.NET MVC5

Question

Currently I am assigned to a project which has a standard view-flow, yet this flow is determined by whether settings are set to either true or false.

So, for example, let the standard flow be View1 > View2 > View3. When the customer has no need for View2, the application should be adjusting this to View1 > View3.

It is quite important to note that these Views do not require any information from eachother and are in no way bound to eachother.

I've thought of some ways to implement this, but I can't really decide which one to use and which one is better or whether there are better options. Consider this Settings object;

public class Settings 
{
    public bool HasView1 { get; set; }
    public bool HasView2 { get; set; }
    public bool HasView3 { get; set; }
} 

Implementation 1: Controller controls

This is the first implementation I came up with;

public class ViewController : Controller 
{
    public ActionResult View1()
    {
        if(!Settings.HasView1)
            return View2();
        else 
            return View("View1");
    }

    public ActionResult View2()
    {
        if(!Settings.HasView2)
            return View3();
        else 
            return View("View2");
    }

    public ActionResult View3()
    {
        if(!Settings.HasView3)
            return View4();
        else 
            return View("View3");
    }

    //etc.
}

Which works fine as-is. However, if I were to implement another ViewN, I would also have to update ViewN-1, which seems inconsistent.

Implementation 2: Some other object which determines the flow based on settings.

Another implementation I came up with is some kind of ViewManager which returnes a View based on the current View and the settings provided. Something like this;

public class ViewManager 
{
    public string GetNextView(string CurrentViewName)
    {
        //Logic to determine the next View
        //I probably have to bind the View names to the settings somehow
        //to achieve this
    }
}

An implementation in the Controller would be as follows, considering View1 is part of the flow;

public class ViewController : Controller 
{
    [HttpPost]
    public ActionResult View1(string currentViewName)
    {
        //handle View Post-logic
        var vm = new ViewManager();
        return View(vm.GetNextView(currentViewName));
    }
}

The second implementation seems to be the better one, yet the first one seems easier to implement.

Any suggestions on why you would choose one over another, or perhaps any other ideas on how to implement this?

Answer 1

First off I think its a mistake to call your controller Methods after the view they return. I think this is creating a conceptual link which doesn't really exist.

Secondly, presumably the actions which the user takes at the end of each view are either the same regardless of the next view, or depend on what the next view is. I could have step 1: submit customer address -> 2: submit customer phone OR 2: submit customer name -- but the action from 1 is always 'submit address'

OR

you might have 1: request Phone Detail Form / 1: request name form

If it's the former then the submit address action should contain the workflow logic, and there is no need to decorate the view model, read the settings from config.

If the the later then the view model should include options for the different buttons which may or may not be enabled

If you do put the logic in the action, then yes, I think splitting it into a different workflow class is probably a good idea, even though it's probably going to be tightly coupled, it will give you the option to change it later and make it easy to see where changes just affect the workflow rather than the individual actions.