ASP.Net MVC vs ASP.Net for Complex workflows

Question

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)?

Answer 1

I just spent some time working on a similar application. My first suggestion would be to get as much workflow stuff out of the application and into a Windows Workflow runtime as you can. It will save you a lot of pain and aggravation in having to manually manage state, etc. AppFabric has recently been released/announced (RTM is June). You can use that to host all of your workflows, and it will take care of persistence and such for you.

Although ASP.NET views are thin, you can have conditional logic in them (to an extent). You can then put the role(s) that the current user is in into your viewmodel. Then in your view code you can check whether a user is in a particular role or not, and render/exclude sections based on that. You can also use things like RenderAction to factor out common sections of your views to avoid a lot of copy/paste programming.

Your code would look something like:

<!-- common html here -->

<% if(  model.UserRole.InRole( [some role] ) ) { %>
    <input type="button" />
<% } %>

Too much of that could lead to tag soup (and there are ways to clean it up), but it sounds like you'll be limited to a handful of actions that a user is able to perform.

The other alternative is to have the list of available actions be passed into the view, then looping through them and rendering teach one. This would take the concerns of user role/etc management entirely out of the views and move that logic further into your business layer (where it probably belongs).

Answer 2

I would definitely use ASP.NET MVC for this. With such a lot of business logic I would suggest that the separated concerns it brings would make both the development and maintainability easier.

Although changing a page to make it look like a different page (remove/add buttons etc.) does work, it's something I am getting more and more uncomfortable with in regards to maintainability because it tightly-couples the UI and the logic. Using Views and Controllers is a better approach in my opinion.

In your situation you would have one Controller with a different Action for each step. Each one of these Actions would return a View appropriate to the user.