locked
From IDbConnection to SqlConnection RRS feed

  • Question

  • Hi. Take for example this inheritance chain:

    IDbConnection <- DbConnection <- SqlConnection

    The members of IDbConnection are the following:

    Function BeginTransaction() As System.Data.IDbTransaction

    Function BeginTransaction(ByVal il As System.Data.IsolationLevel) As System.Data.IDbTransaction

    Sub ChangeDatabase(ByVal databaseName As String)

    Sub Close()

    Public Property ConnectionString As String

    Public ReadOnly Property ConnectionTimeout As Integer

    Function CreateCommand() As System.Data.IDbCommand

    Public ReadOnly Property Database As String

    Sub Dispose()

    Sub Open()

    Public ReadOnly Property State As System.Data.ConnectionState

    DbConnection implements only these members:

    Function BeginTransaction() As System.Data.IDbTransaction

    Function BeginTransaction(ByVal il As System.Data.IsolationLevel) As System.Data.IDbTransaction

    Public ReadOnly Property ConnectionTimeout As Integer

    Function CreateCommand() As System.Data.IDbCommand

    Sub Dispose()

    leaving SqlConnection the implementation of the other members. I was asking myself if I was able to guess which members DbConnection could implement and which not. Sometimes I succeded, sometimes I din not succeed. My logic was that when a member is strictly tied to the implementation of the data provider, DbConnection should leave the implementation to the data provider, when a member is "more general", DbConnection should implement it directly. The problem is that, when it is not straightforward like Dispose(), I have many difficulties to imagine which members are strictly tied to the data provider. For example, how is it possible to understand that BeginTransaction() should be implemented by DbConnection? Really, this is one of the methods which compares twice in the SqlConnection implementation, but more in general, I would like to learn a practical rule that let me understand in which level of the inheritance chain a member should be implemented. Is it possible without giving a look at the real implementation of a data provider? Thanks.

    • Moved by Alexander Sun Friday, August 10, 2012 7:34 AM Move to more appropriate forum. (From:LINQ Project General)
    • Moved by Val Mazur Wednesday, August 22, 2012 2:01 PM (From:ADO.NET DataSet)
    Thursday, August 9, 2012 12:33 PM

Answers

  • The IDbConnection interface defines the common functionality of the connections, so any ADO.NET DbConnection should implement those members. Then if you look at the inheritance DbConnection is abstract class that implements IDbConnection, part of it expilicitly, and if you look at the source code you see that for example BeginTransaction method that DbConnection implements actually calls protected abstract method BeginDbTransaction and that is the method that actual provider specific connection instance, like SqlConnection, must implement to make it possible to begin transaction in correct way. Those abstract methods in DbConnection are the ones that each provider specific connection instance must implement to make the method functional for the database server provider is used. Many public methods that DbConnection implements actually maps to protected abstract methods and some other that do not, like EnlistTransaction method throw not supported exception and mark method virtual so provider specific connection classes can override implement this if they do support transaction listing.

    Hope this is helpful.

    • Proposed as answer by Bob Wu-MT Wednesday, August 15, 2012 6:04 AM
    • Marked as answer by Bob Wu-MT Wednesday, August 22, 2012 7:27 AM
    Friday, August 10, 2012 6:45 PM
  • Hi speculor,

    Base on my knowledge, the Visual Studio Object Browser can display all accessible members. However, we can't access the friend member of the System.Data assembly. If you declare a friend member in your project, then you can view it in the Visual Studio Object Browser. In addition, you need to check the Show Other Members, for more details, see http://msdn.microsoft.com/en-us/library/exy1facf(v=vs.100).aspx

    The Reflector using reflection which enable you to obtain information about loaded assemblies and the types defined within them, such as classes, interfaces, and value types. For more details about reflection, see http://msdn.microsoft.com/en-us/library/f7ykdhsy(v=vs.100).aspx

    Best Regards,


    Bob Wu [MSFT]
    MSDN Community Support | Feedback to us

    • Marked as answer by Bob Wu-MT Wednesday, August 22, 2012 7:27 AM
    Wednesday, August 15, 2012 6:04 AM

All replies

  • The IDbConnection interface defines the common functionality of the connections, so any ADO.NET DbConnection should implement those members. Then if you look at the inheritance DbConnection is abstract class that implements IDbConnection, part of it expilicitly, and if you look at the source code you see that for example BeginTransaction method that DbConnection implements actually calls protected abstract method BeginDbTransaction and that is the method that actual provider specific connection instance, like SqlConnection, must implement to make it possible to begin transaction in correct way. Those abstract methods in DbConnection are the ones that each provider specific connection instance must implement to make the method functional for the database server provider is used. Many public methods that DbConnection implements actually maps to protected abstract methods and some other that do not, like EnlistTransaction method throw not supported exception and mark method virtual so provider specific connection classes can override implement this if they do support transaction listing.

    Hope this is helpful.

    • Proposed as answer by Bob Wu-MT Wednesday, August 15, 2012 6:04 AM
    • Marked as answer by Bob Wu-MT Wednesday, August 22, 2012 7:27 AM
    Friday, August 10, 2012 6:45 PM
  • Thanks for your answer. I imagine that I should use Reflector in order to understand the actual implementation. I have realized that using Reflection I can find members that I can not find using the Visual Studio Object Browser. I have the impression that those members are Friend. Is it correct? Is there any reason for that? Sorry but, may be I am loosing something.

    Monday, August 13, 2012 3:29 PM
  • Hi speculor,

    Base on my knowledge, the Visual Studio Object Browser can display all accessible members. However, we can't access the friend member of the System.Data assembly. If you declare a friend member in your project, then you can view it in the Visual Studio Object Browser. In addition, you need to check the Show Other Members, for more details, see http://msdn.microsoft.com/en-us/library/exy1facf(v=vs.100).aspx

    The Reflector using reflection which enable you to obtain information about loaded assemblies and the types defined within them, such as classes, interfaces, and value types. For more details about reflection, see http://msdn.microsoft.com/en-us/library/f7ykdhsy(v=vs.100).aspx

    Best Regards,


    Bob Wu [MSFT]
    MSDN Community Support | Feedback to us

    • Marked as answer by Bob Wu-MT Wednesday, August 22, 2012 7:27 AM
    Wednesday, August 15, 2012 6:04 AM