ASP.NET MVC - problem logically undertanding how to structure a report section

Question

The problem: Using ASp.NET MVC for reporting.

Given: 1. A report that is tabular in output, so it can easiyl be represented by a class (static field list). 2. A filter mask containing halfa dozen or more possible conditions to apply to the data.

How is the approach for the MVC file layout?

1. I would say one controller for the complete report.
2. But how does the model look? One property with all the filter conditiond (or: a property per filter condition), one property with an enumeration of results?

I would also love to do a redirect when the search parameters change and would love to see the parameters as parameters (i.e. the URL ending in /Reports/Assets?From=...&To=...) so users can bookmark a specific favourite report or email the URL around.

How to do? I have a lon gbackground in ASP.NET, but MVC somehow eludes me ;)

Answer 1

Thoughts rather than answers:

In MVC the ideal is to send to the view pretty much just the data to be rendered by the view, if that's something from your base model then that works nicely if its something specific to the view (or a group of views) then that's what you do.

In so far as possible you don't want decision logic in your view - and if there is decision logic that really should be concerned just with how to render a specific element, so the simplest model for your report is just the rows of data (something IEnumerable) and the view is just a foreach.

That then makes the controller's job one of building the query and passing it (or the results, depending on what works) to the view.

Initially I considered that you could instead pass the unfiltered data and a filter to the view and then you are still doing a foreach but to the raw data with the filter attached... but having worked my way through this slowly that's nowhere near as neat.

Becuase all the filter logic is in the controller (the view just outputs the query result) you can pretty much do what you want with the URLs - your view is either report specific or you can have a more generic view and pass in the column type/heading/format data as well as the row data others should comment on the advisability of that...