ADO.NET suggestions

[Gleb Holodov]

Dear all!

I don't know if anyone has ever experienced the same problems as I did, but
I would like to suggest a number of changes or at least directions of
re-engineering which, once implemented, will make ADO.NET faster, more
flexible and better than it was at all.

1) it's really annoying that I cannot filter off the rows in a dataset
that I pass to IDbDataAdapter.Update. The most common (but not the only one)
would be to filter by DataRowStatus - like Modified, Deleted, etc.
The standard recommendation is to first call GetChanges and then feed a
data adapter with a "changes-only" dataset: someAdapter.Update(
ds.GetChanges( DataRowStatus.Deleted ) );

Although this way seems to be quite natural, it has a number of
problems:
a) perormance problems beacuse of unnecessary copying: all modified
rows and rows, with at least one of the descendants modified, will be
copied, not just referenced in a derived dataset.
b) loss of accept/reject and error info information: a data adapter
sets this info for rows of a dataset returned from GetChanges, and it's a
real pain-in-the-* to migrate these changes back to an original dataset.

From my perspective, it would be much more natural to have a way to
create some sort of DataSet View, say, DataSet.CreateView( ds,
DataSetFilter.ByStatus( DataRowVersion.Deleted ) ), and feed it to
IDbDataAdapter instead of original DataSet itself.

2) when I write ado.net-provider-idependent code, I cannot (without
having to use emit) bind to RowUpdating/Updated events: they all have
different signatures and so I cannot bind a single pre-written
provider-method to handle these notifications.
The problem is that delegates expect methods with exactly matching
signatures as their parameters. Yes, it's safe, but it's really annoying,
since it doesn't take polymorphism into account. Why can't I write an event
handler zzz(object, object) to handle events of any kind?? I suppose, there
could be some performance and security issues I'm unaware of, which kept
..net developers from allowing this, but again, in the way it's done, it's
VERY unflexible.

3) the framework doesn't allow me to extend it even for a little bit:
although DataSet is inheritable, it greatly limits inheritors. For example,
it would be possible to create DataSetView class as a subclass of a DataSet,
if only DataSet.Tables and DataTable.Rows properties had been virtual. But
they're not. Sob.

4) DataSet can perfectly explain what's wrong with a new row that I'm
trying to insert into its table (like FK, PK or check constraint violation),
but it's ultimately laconic in EnableConstraints() - it doesn't give a clue
on what's wrong.

5) Bad support of complex relationships - there're cases when
DataSet.GetChanges runs into stack overflow if there're circular
relationships (whether direct or indirect).

Thanks,
Gleb

 

[Cor]

Hi Gleb,

Can you give us an idea what the performance benefits will be in seconds
from one dataset update it your recommandations will be implemented?

I think it will be nothing comparing with a simple repaint of the screen.

But maybe I am wrong

Cor

 

[Gleb Holodov]

Cor,

repaint of the screen takes clients' time - i don't care that much about it.
Propagating changes from data layer objects (dataset) to a database takes
cpu time and memory on the server (I have a service-based distributed
application, and these are only services-on-servers that ever deal with
ADO.NET) - that's what I'm really concerned of, since every redundant
resource usage decreases the system throughput => makes me demand more
performing hardware => increases the collateral cost of the solution.

Replying to your question:
1) performance gains depend on the actual dataset schema and profile of the
changes that it suffers. In the worst cases, the gain may be up to 100%.

2) again, it's not only about performance, but abou the contradictory
nature of ADO.NET. On one hand, it's said to be RAD - you can do almost
everything you need at design-time with the help of handy designers, and
then just plug-in very simple, small and straight-forward code at run-time.
Okay, not always. If I use GetChanges to segregate "forward" (insert,
update) and "reverse" (delete) changes to datasets, then write two sequences
of calls to my data adapters, then write the code to transfer back
accept/reject and errorinfo data from those derived datasets into an
original one, - is it what's called RAD?

3) I understand the aspiration of .NET developers to minimize the
public/protected part of the interface in order to simplify future
development by not limiting themselves with necessity to support
seem-to-be-implementation-details code, but just a little bit of flexibility
(like turning .Tables and .Rows into virtuals) would've eased the situation
dramatically without really bringing any headache to MS developers.

4) have you ever tried to create some real (enterprise, not sample code)
code that has to be ado.net-provider-independent? If not, please do, and I'm
pretty sure you will run into the same problems that I did.


Once again, things that I wrote were just suggestions - you may agree or
disagree. I was able to work around all of the aforementioned issues in one
or another ugly way, with one or more //MS BUG or //DARN comments around,
but man, I'd really like to see my favorite framework shining - is it bad?

Gleb

 

[Cor]

Hi Greb,

I do not think that the wizards are really something to use to develope in
an enterprise environment.

I think that almost everybody who really understand how to make programs
will stop after 3 months using the wizards completly.

But RAD can be archieved by using dotnet by the almost endless posibilities
by creating your own things, controls, classes, etc..

This makes it that dotnet is good for a single user programmer but in my
opinion also for an endless development environment, where task are divided
and everybody makes his components tailored to the organization. (But it
will cost a lot of time that I agree to make some switches).

I agree with you that the documentation is in my eyes is mostly made for
that single user programmer. (But the rest is I think often very company
dependable).

Just my thought,

Cor