Cam someone please explain what could be the advantages by not giving SqlDataReader a public constructor. what is the benefit of not creating SqlDataReader object with a new Keyword.
Thanks, Tinks
1 Answer
The SqlDataReader was designed to only be created using the results of a SqlCommand or some other data source in the ADO.NET framework. I would assume that enumerating the results of a query across a connection to a SQL Server database would require a number of internal implementation aspects to be present for the reader, which anyone outside of the ADO.NET classes themselves wouldn't have any way to provide.
If you wanted to create a datareader yourself (which you only ever need to do if you're implementing a new data provider), there's the IDataReader interface for that.
If you wanted to customize the datareader behavior (e.g., if you're writing a wrapper library for ADO.NET that provides some additional behavior like automatic logging of exceptions, automatic retries, etc.), then you would want to encapsulate the SqlDataReader by making it a private member of whatever class you're creating (e.g., say you're creating an ExceptionLoggingDataReader). You're not really changing the SQL data access behavior itself, which is why subclassing the SqlDataReader isn't a permitted option.
