Question from the ADO.NET Team

  • Thread starter Thread starter Pablo Castro [MS]
  • Start date Start date
P

Pablo Castro [MS]

We are interested in hearing some opinions on a change we've been
considering:

Currently most classes in ADO.NET such connection, command, datareader,
parameters, etc. inherit from MarshalByValueComponent, MarshalByRefObject or
Component. This is actually not needed or useful (i.e. you can't actually
use most of these through remoting directly) and it adds certain overhead
that we'd like to remove.

We believe that there is no actual reason for application code to depend on
the fact that we inherit from those, but we don't want to make a change
unless we're really sure that this is not an issue for existing
applications.

So the question is: is anyone depending on the fact that we inherit from
those classes for your applications? If so, what's the scenario where that
happens?

Scenarios I can think of:

- Do you rely on the fact that connection, command and adapter inherit from
component? If so, would it be enough if we implement IComponent instead?
- Do you directly expose any of the ADO.NET classes *directly* through
remoting?

The ADO.NET team would really appreciate your input in this matter. Feel
free to either answer to the newsgroups or email me directly.

Thanks in advance.

btw - what's your opinion on us doing this kind of polls in the newsgroups?

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
My code does not depend on specific inheritance trees.
I like the polling approach.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Hi Pablo,

I do not rely on it in my development. My personal opinion is that percent
of developers, who use remoting in their development, relatively is not so
big. Percent of those who rely on inheritance of component is even smaller.
So, I do not think you will get much response on this issue here.
 
I work as an independent consultant and I have seen more than one companies
remote datasets and strongly typed datasets. I know it's not a good idea
etc. etc. but people have done it quite a bit out there. While what you are
suggesting is a good idea, I would keep a backdoor for those customers.

- Sahil Malik
You can reach me thru my blog -
http://www.dotnetjunkies.com/weblog/sahilmalik
 
Hi,

Thanks all for the responses. Just to clarify, DataSet serialization will be
intact, no changes there. Also, this change won't affect applications that
use remoting for their own types; it will only affect applications that
attempt to remote the actual ADO.NET connected-stack objects such as a
command or a data-reader directly.

Thanks,

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Pablo said:
We are interested in hearing some opinions on a change we've been
considering:

Currently most classes in ADO.NET such connection, command, datareader,
parameters, etc. inherit from MarshalByValueComponent, MarshalByRefObject or
Component. This is actually not needed or useful (i.e. you can't actually
use most of these through remoting directly) and it adds certain overhead
that we'd like to remove.
Click to expand...

I wholeheartly agree :)
We believe that there is no actual reason for application code to depend on
the fact that we inherit from those, but we don't want to make a change
unless we're really sure that this is not an issue for existing
applications.

So the question is: is anyone depending on the fact that we inherit from
those classes for your applications? If so, what's the scenario where that
happens?
Click to expand...

No, not me, on the contrary.
Scenarios I can think of:

- Do you rely on the fact that connection, command and adapter inherit from
component? If so, would it be enough if we implement IComponent instead?
Click to expand...

I'm not sure if this will impact design time controls though.
- Do you directly expose any of the ADO.NET classes directly through
remoting?
Click to expand...

No. What I do like to see is a way to serialize for example SqlParameter.
The reason for this is that in our O/R mapper system we generate SQL on the
fly and in very large systems where layers are distributed across a farm of
systems, developers want to cache queries being generated and want to
distribute these objects over the wire. Because SqlParameter is for example
not serializable, you can't do that now.
The ADO.NET team would really appreciate your input in this matter. Feel
free to either answer to the newsgroups or email me directly.

Thanks in advance.

btw - what's your opinion on us doing this kind of polls in the newsgroups?
Click to expand...

A very good initiative. Please, with more questions, issue again a poll,
it's a great way to provide feedback directly :)

thanks!

Frans.
 
Hi Pablo,

Pablo Castro said:
We are interested in hearing some opinions on a change we've been
considering:

Currently most classes in ADO.NET such connection, command, datareader,
parameters, etc. inherit from MarshalByValueComponent, MarshalByRefObject
or
Component. This is actually not needed or useful (i.e. you can't actually
use most of these through remoting directly) and it adds certain overhead
that we'd like to remove.

We believe that there is no actual reason for application code to depend
on
the fact that we inherit from those, but we don't want to make a change
unless we're really sure that this is not an issue for existing
applications.

So the question is: is anyone depending on the fact that we inherit from
those classes for your applications? If so, what's the scenario where that
happens?

Scenarios I can think of:

- Do you rely on the fact that connection, command and adapter inherit
from
component? If so, would it be enough if we implement IComponent instead?
Click to expand...

For simple applications or when I test something I drop classes on the form
and configure it there.
For other application I create data objects using CodeSmith and I don't rely
on anything you've mentioned.
- Do you directly expose any of the ADO.NET classes *directly* through
remoting?
Click to expand...

No, but I am not much into remoting.
The ADO.NET team would really appreciate your input in this matter. Feel
free to either answer to the newsgroups or email me directly.

Thanks in advance.

btw - what's your opinion on us doing this kind of polls in the
newsgroups?
Click to expand...

Refreshing addition (in contrast to few different questions that appear all
the time at this newsgroup :-) )
 
The only area I could think of would be using remoting and returning a
DataReader. The Connection would have to be Remoted. As there are other
methods of returning data, there is no real issue here, IMO.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
 
Back
Top