Pass an instantiated base class to a new class that inherits the same class -- Possible??

[Brad Navarro]

OK, I may be asking for the impossible, but I'll give it a shot: For a case
like this:

using System.Data.SqlClient;
abstract class Base
{
private SqlConnection DBConnect;
Base(string SqlConnectStr)
{
DBConnect = new SqlConnection(SqlConnectStr);
}

// Some other base code here that relys on the DBConnect object
}

sealed class Derived1 : Base
{
Derived1(string ConnectStr):base(ConnectStr)
// etc
}

sealed class Derived2 : Base
{
Derived2(string ConnectStr):base(ConnectStr)

void func()
{
Derived1 DerivedObject;
// here I would like DerivedObject to inherit the Base class already
// instantiated by Derived2 (so that it uses the same SQL Server
connection), rather than creating it's own instance
DerivedObject = new Derived1();
}
}

I would like for Derived2 to pass the SqlConnection that Base has created
for it along to Derived1 when it creates an object for it; from my thinking,
it would be nice if there was some way to force Derived1:Base to accept
Derived2:Base's object rather than instantiating its own.

I can think of two potential solutions, neither of which is very appealing
to me. The first is to create a new Base constructor that takes a
SqlConnection, and make it's internal SqlConnection protected.
Unfortunately, this is code in a DLL, and because C# has no concept of
friend classes, this creates a sort-of "backdoor" situation whereby a) any
derived class from Base can mess with the SQL Server Connection, and b) it
creates an unwanted API interface that allows "unauthorized" code to inject
a SQL Server connection. The other solution would be to simply pass the
ConnectStr string and create a new SQL Connection, but I would also like to
limit the number of connections that I make if possible because there exists
the potental for a lot of database connections already within the scope of
the overall app.

Any other solutions to my dilemma?

 

[Mickey Williams]

SQL Server connections are already pooled. If you use a consistent
connection string across your connection requests, then aquire late and
release early the connections will be pooled automatically by the runtime.
You're looking at quite a lot of work if you want to re-invent the wheel and
implement a homegrown pooling mechanism.

And you can't share superclasses instance identity among multiple subclass
instances.

 

[Philip Rieck]

Brad:

Before I go on, note that I also agree with Mickey on the connection
pooling - why reinvent your own?You're normally better off creating (new)
and destroying (dispose) your connections in as short a scope as possible.

1) C# does have a concept like "friend" - it's "internal". This limits
accessibility to callers in the same assembly. (note that it is like
private - you can get around it with reflection)

2) You could use somthing like this static hashtable to store connections.
I don't recommend this particular solution, because it will keep the
connections around for the life of the appdomain - probably the life of your
application. However, you could 'tweak' it to remove the instances of the
connections, but then you're reference counting. Again, go with .net's
connection pooling.

abstract class Base
{
...
private static Hashtable connections = new Hashtable();
Base(string SqlConnectStr)
{
if( connections.Contains(SqlConnectStr))
{
DBConnect = (SqlConnection)connections[SqlConnectStr];
}
else
{
DBConnect = new SqlConnection(SqlConnectStr);
connections.Add(SqlConnectStr, DBConnect);
}
....
}

 

[Jeffrey Tan[MSFT]]

Hi Brad,

Do you still have any concern?
Please feel free to let me know.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.