Opinion: best way to retrieve/list data using .net mvc

Question

Hi all, I'm new with the MVC framework and I was wondering what you think is the ideal way to retrieve data and list it on a page. Specifically, I'm referring to data used in report type pages, not lists of movies, books, or other clear 'objects'.

Most online samples seem to suggest using ADO.net Entity Data Models & LINQ which are automatically built by the wizard using the DB schema - and that seems great for things like movies/books, but doesn't seem so intuitively 'correct' for random data needed for a report.

This may be too vague/broad of a question, but any help would be appreciated.

Update: To be more specific, I basically need to take a set of rows from a Sql server view and display them on a page. Some of it just in a list, and some in graphs (planning to use the .net charting control). I realize what I'm doing is very simple, I'm just not sure what the best way of doing it using the MVC framework is. Hope that clears it up a bit...

Answer 1

I'm not sure if this question can be answered without knowing specific requirements. If your looking for something to take any random data then you have a really unique issue because no C# ORM mapper ( Linq2Sql, NHibernate, Entity Framework, SubSonic ) will just autocorrect things for you.

The issue is the common practice of creating C# classes which map to your data. You can't just change them without a recompile. I guess dynamic objects would work but there isn't a dynamic ORM mapping system that will work with them.

Pretty sure your looking at rolling your own tooling with the Ado.net libaries to handle dynamic tables and data sources.

Answer 2

Just group the data the best way you can into some container object, and use that container object as the Model for your View. Your model can easily pick and choose aspects of the objects that are generated by your ORM to populate itself with.

Each report page can inherit from a unique Model object, so each report can know about the different data it needs.

(Note: Sometimes this is called a "ViewModel", since it's an amalgamation of the different model pieces that you need for your view, but it isn't exactly a real object in your domain modelling. However, more strictly a ViewModel has other connotations when you're using it in MVVM style designs.)

Answer 3

Keyword "reporting" makes me think of intense queries. Use stored procs for that. Otherwise EF all the way! woooo