Using interfaces for managing disparate requirements across shared MVC Views

I'm working on a web-application which has the ability to generate multiple HTML "reports". Previously, reports each had their own controller, models & separate views implemented as ".ascx" pages that were loaded into a common "Display.aspx" page when various reports were selected.

However, as this application has developed, we have identified a lot of common components between some of the report pages, I.e. charts / title page / certain disclaimers, which have been forked out as common ascx pages that could then be loaded by a given report. If these common pages were static HTML, that'd be straightforward, however most require passing certain model parameters to generate the page, and each often require different parameters, and this lead to the problem I'm now facing:

In these instances where reports had multiple common fields, the previous developer elected to use the same model. So any of these common views & the main report itself all received an object which can contain any of the parameters required for all of the shared views and any of the report parameters which use a common view. What this has led to is a mongrel of an object which has dozens and dozens of parameters, even when using a relatively simple report. In most cases, a lot of these fields are left uninitialized by the governing controller, as they are simply not required. While this works, I feel it's not a particularly good design philosophy, which lead me to asking:

1. Is the above scenario acceptable, and
2. What's a better alternative for managing these common views?

What I came up with, but wanted some feedback on, was:

• Requiring a specific interface for each common view; one that only has the fields required for generating it.
• Creating a unique model for each report & have it implement the required interfaces to support the specific common views that specific report uses
• When generating the common pages, let .NET "upclass" the report object to get the necessary fields, but on the common page itself, it's dealing with a much more general object

But are there caveats to this approach? Or something better / commonly done in situations like this?