Perhaps this is just completely wrong, but back in the days of Webforms you would return a Dataset which you would then bind to a grid. But now in MVC you’re not supposed to pass a datatable because you cannot serialize it and it’s technically passing objects into the View where it doesn’t belong? But how on earth am I meant to display data on a view?! I can’t use LINQ to SQL classes here since this is a pure in memory data structure.
Ideally I’d just like to able to have an object which I can iterate within the view.
I’m really at a bit of a loss I have read the article from the “Gu” and I can only summarize that I have to pass back a ViewData Object instead?? Am I going nuts here?
Cheers from Blighty
Jon
This is not “wrong” at all, it’s just not what the cool guys typically do with MVC. As an aside, I wish some of the early demos of ASP.NET MVC didn’t try to cram in Linq-to-Sql at the same time. It’s pretty awesome and well suited for MVC, sure, but it’s not required. There is nothing about MVC that prevents you from using ADO.NET. For example:
Controller action:
View: (w/ Model strongly typed as System.Data.DataTable)
Now, I’m violating a whole lot of principles and “best-practices” of ASP.NET MVC here, so please understand this is just a simple demonstration. The code creating the DataTable should reside somewhere outside of the controller, and the code in the View might be better isolated to a partial, or html helper, to name a few ways you should do things.
You absolutely are supposed to pass objects to the View, if the view is supposed to present them. (Separation of concerns dictates the view shouldn’t be responsible for creating them.) In this case I passed the DataTable as the actual view Model, but you could just as well have put it in ViewData collection. Alternatively you might make a specific IndexViewModel class that contains the DataTable and other objects, such as the welcome message.
I hope this helps!