I have just become involved in migrating a series of complex workflows with InfoPath UIs to Web-based UIs. I am new to ASP.Net MVC but have started to evaluate it as the technology versus classic ASP.Net for the job.

As is typical of most workflows, in each state there are a number of business rules that determine (a) who can view what content; (2) who can edit what content; (3) what the user action options might be (Edit; Reject; Approve), etc. In essence, there is a lot of logic that needs to be applied to each request before presenting the appropriate view. Being more experienced in ASP.Net, I know that presenting the form(s) as required can be easily achieved through code behind pages (enable / disable / hide fields). I have not seen how this can be achieved with ASP.Net MVC (but am realising that new thinking is required of me when working with MVC - ‘Give only the content on a particular View + limited user action options’).

Therefore, if using ASP.Net MVC, it looks like I would need to create a lot of views. Much of the content in each view would be the same. Only field enabled status or buttons would differ in most instances for these views in each state. For example: Step01Initiate (‘Has Save’ button); Step01OriginatorView (has ‘Edit’ Button) ; Step01OriginatorEdit (has ‘Save’ button); Step01Review (has ‘Accept’ / ‘Reject’ buttons); Step01ReviewReject (for reviewer notes; has ‘Save’ / ‘Cancel’ buttons). With workflows of up to six states, this would result in a lot of views. I can see the advantages of choosing ASP.MVC (1) ‘thin’ Views in terms of content; and (2) with logic consolidation in Controllers and different Models.

Am I thinking along the right lines in terms of applying the MVC – ‘plenty of views’; or is there a better way to achieve my goal (using ASP.Net MVC or classic ASP.Net)?