I've been using the Dataset designer this week for a project we are building in ASP.NET using VS 2005.
If there's a way for me to turn off the automatic creation of a DataAdapter for each table I drag out onto the designer surface, someone please tell me now!
Really, I suppose for quick-n-dirty developing, having it automagically created could be useful. But I have both philisophical and user experience reasons for not liking it at all.
Philisophically, this just doesn't fit in with the way I fill datasets. I have a data access service (either a web service or an assembly) that takes a typed dataset and a set of criteria and fills the dataset with one call. I have a stored procedure generator that creates stored procedures that the service calls - the Select sprocs (SelectAll, SelectPK, SelectFilter) understand the "main" table in each dataset and apply the criteria to those, and return a multiple resultsets to the service, which fills each table in the dataset. So one call does the whole dataset, not one call per table. When persisting changes, the service takes the dataset, extracts the changes, and iterates through the tables, creating its own DataAdapters and doing the Insert, Update, and Delete methods. So, again, from the point of view of the consumer of the data service, one call does it all again.
From a user experience, I am dropping a table onto the designer, then I try to select the DataAdapter portion that is below the table definition - if I don't get just that adapter selected and press Delete, the whole table and its adapter is gone. If I do get the adapter selected, when I hit Delete, I get a "mother-may-I" question - "This will delete the data adapter. Do you want to delete the table as well?" Now, when you hit Delete in pretty much any other program or function, normally the prompt message box is phrased so that "Yes" means "Yes mother, I want to delete this [thing]." So while I am already annoyed at being forced to delete something I didn;t want in the first place, half the time I answer Yes to the Delete question, and end up deleting both the adapter and the table itself. Fortunately, the Undo brings back (both) the table and the adapter. So I find between the difficulty in selecting the adapter only and the oddly-phrased question, I am about 50% productive in the DataSet designer. (for the record, I don't think the "mother-may-I" question is necessary in this case at all).
Along the same lines, I have been finding the ObjectDataSource ASP.NET control somewhat useful with the controller classes I have been making for the business logic. With a little adjustment, I have been able to use it for the Select operations and binding to databound controls. However, I have been finding it tough to use the updating methods on the datasources, because they assume again, that we are updating a single table at a time. I would like the DataSource objects to fetch a dataset and "host" it within the container, allow access to the data from various controls (different grids or tabs are bound to different tables), and then make a single call to persist all the changes at once. It seems to me that the databound controls that allow editing, inserting, deleting, etc, all want to force the persistence call on the datasource, rather than simply doing their work of collecting the changes and notifying the datasource that the data has changed. Perhaps another UI control could then notify the datasource that the user requested the changes to be persisted (or abandoned). In other words, I want each of the editing controls to allow for changes without forcing the persist to occur immediately.
Maybe there's a method I can overload or an event I can catch to get this behaviour to work the way I want it to. But I haven't looked for that yet.