Mike Lorengo and I are having a fantastic dialogue about complex objects and handling the display of their information in grids. I do recommend you read his post before continuing here. Don't mind me... I'll wait...
Ok now that you're back I'd like to explain a little deeper on my preference for domain queries that return data tables to populate grids instead of the other methods Mike goes into. Yes, my main gripe with such a method is the performance concern. Mike's post, and the feedback he's received the main concern has been about executing many calls instead of one call.
Mike answer's these concerns by giving four ways that you can handle databinding these complex objects:
- Return a DataReader of Wine records, and then lazy load the WineVarietal (and Varietal) records in another DataReader as needed
- Return a DataReader of Wine records and for each one get another DataReader to load the associated Varietal information
- Return a DataReader of Wine records with multiple INNER JOIN's and iterate through the records building the Wine and Varietal information
- Issue a batch of Sql Statements for each set of information and use the IDataReader's NextResult() method to advance the DataReader to the next result set while building the Wine and Varietal information.
This is all well and good but the point that I wanted to get across is that the purpose of binding the information to the grid is to display summary information. We're not exposing any specific object calls to the summary information except the load of referential data. In this case, the end result is that we are using a collection of complex objects as a datatable. So my point, in the end, is if you are trying to act like a datatable, you might as well be a datatable. It'll save you all the time of parsing those datareaders and building objects whose functionality you aren't really using.
Great discussion Mike. I love blogging for the same reasons you do.