Introduction

I am designing an MVC webapplication using Umbraco. As those of you who develop on Umbraco should know, you can specify page hierachy through the backoffice. At this point in time, I have several views that all stem from eachother (A/e, Master -> Container -> Form1/Form2/Form3). The "typical" implementation that I am aware of is to Hijack the route from Umbraco using a template controller (RenderController) and then reconstruct the pages bottom-top (Form1 controller renders the view, the view decides it needs container view [through the layout field], which then decides it needs the master view).

Now let's hypothetically say that in each stage of this process, I want to do the same tasks (so the master will run the same code during each page request, followed by the Container, followed by the form) and these tasks are commulative, such that I don't want to do each more than once (to visualize, imagine permission systems with Master requiring the least permission to use, and Form1/2/3 requiring the highest permissions). The gimmick is that form1 may be acceptable to view, however container/master are not (thus causing me to redirect the user to where they need to go). Rather than waiting for form1 to finish, it would be faster to check master, followed by container, followed by form1.

Problem

My problem is that I am having a difficult time deciding what approach I should be using in designing this. My options are varied significantly, so let's outline them:

1. Go the "Default" route, where form1 is requested, which will run through the form1 controller and then render the rest of the application using the Layout field, duplicating code throughout the entire process (so form1/form2/form3 all run the same code as container and master). Highly inefficient, as form1 may not even be valid after container/master have their say

2. Use controller inheritance, such that when form1 is requested, is calls the Container controller, which then calls the master controller (and then runs down the pipe until we're back to the form controller). The problem here is visualizing the structure, and still taking the advantage of partials, @RenderBody(), etc.

3. Ignore form1/2/3 and just dynamically render Partial Views from the Dashboard controller (potentially taking in data from the model/querystring/other data to decide the state). This feels slightly dirty, and may make code unmaintainable in the long run.

I can see benefits and detriments to all three options, but my biggest worries are:

1. Code Maintainability
2. Code Complexity
3. Best Practice

Question

How would you go about designing your MVC Application Controllers to reduce code re-use, improve runlength/response times, and to reduce code complexity?

I posted this on Stack overflow, however they seemed to think that this question better belonged here.