RSH said:
I have a situation where I have a class which manages different data
connections. In trying to enforce encapsulation I have a member field
called connection which could be a type of SQLConnection, or OleDBConnection
etc. When I am setting up the field how can I say it might be type of SQl or
type of OleDb?
You can use any class common to both with respect to inheritance. MSDN
provides detailed information regarding the inheritance hierarchy, so
this should not be difficult to determine. In this particular case, the
most-derived common class is DbConnection and the least-derived common
class is (as is always the case) Object.
So you could encapsulate your connection as either of those classes, or
even one of the intermediate ones (though it's hard for me to see why a
MarshalByRefObject or Component would be a logical choice, you could in
fact use either of those as well).
I prefer to use the most-derived common class, so in your case you would
use DbConnection.
Of course, when you go to use it, if you need to use class elements
specific to SQLConnection or OleDbConnection, you'll have to cast the
instance reference to the appropriate type. You can use "is" to test
for the specific type, and either "as" or more conventional for casting
("as" has the advantage of essentially combining the test and the cast
into a single statement).
or...
Should I be using a base class that contains all of the common methods, and
then setup concrete classes that setup the data specific fields, methods?
This is a completely different question. You could in fact create a
base class for your own use, if you have class members that will be
specific to the SQLConnection or OleDbConnection. The base class would
include the members that don't care what the type of the connection is,
while the derived classes would include the members that are specific to
the type of connection.
But if you want a single member to store the connection, you still need
to use DbConnection or similar to represent that connection, and your
new derived classes would still need to cast that member as appropriate
(though because of the derived classes you could at least skip the step
where you check the actual type of the connection...presumably in each
derived class you would only have a connection type appropriate to that
derived class).
The question of creating a base class and associated derived classes is
not strongly tied to the question of using a single variable typed to a
common base class to store the reference to the connection.
To sum up:
* You can use a base type to represent an instance that could be
one or the other of a derived type. This is useful whether you create
your own base/derived class hierarchy to deal with the methods and other
elements related to the connection.
* You can optionally create your own base/derived class hierarchy,
where the base class contains the shared connection reference (typed as
above to DbConnection), and the derived classes contain any behavior
that is specific to one or the other derived connection types
(SqlConnection or OleDbConnection).
Pete
