I wonder why they didn't mimic BaseDataList's (what Repeater, DataGrid, and DataList extend) idea of a DataSource property that accepts an object. That would allow the user to pass in an IList of entity objects.
If DataTables are to be supported, here are some cases they should handle: Ability to pass in strongly typed DataTable to be populated Ability to return new strongly typed DataTable based on column types Ability to return new non-strongly type DataTable A more general statement might be to say that DataTable support should mimic IList support. I'd vote +0 for it. I'm sure it will come in handy at some point. --- Ted Husted <[EMAIL PROTECTED]> wrote: > On 5/18/05, Brandon Goodin <[EMAIL PROTECTED]> wrote: > > As a side note. After having toyed with DataSets... I am hard > pressed > > to see their value in the long run. It's like the EJB of the .NET > > world. It's not neccesarily as complex... but it is certainly full > of > > just as much hot air. > > One value I'm running into now is "playing nice with others". > > We're testing a third-party component, Aspose.Word, > > * http://www.aspose.com/Products/Aspose.Word/ > > and the API uses DataSets and DataTables for the more interesting > master/child reports. > > Right now, we're using some simple glue code to convert a HashTable > into a DataTable, so that we can pass it to Aspose.Word. Of course, I > keep thinking that it would be cool to return a DataTable via a > ResultSet instead. :) > > In my own use case, I don't need a bidirectional, disconnected > DataSet. We just need to create a DataTable to pass to this other > API. > > -Ted. >
