Extending MSDAAB

  • Thread starter Thread starter Greif
  • Start date Start date
G

Greif

I am looking to extend Microsoft's Data Access Application
Block so it can access Oracle, OLEDB, ODBC in addition to
the default SQL Server.

I am pretty sure it is better to use abstract classes than
interfaces as ther will be lots of exposed methods and some
code will be generic enough to place in the base class.

What I am planning on doing is creating an abstract base
class that has as much functionaliy coded (using the
System.Data Interfaces) as I can get in there. Then have
seperate classes (i.e. different data providers) that
extend the base class.

Does this seem like a viable idea? Or am I setting myself
up for disaster? Does anyone have any thoughts, comments or
suggestions? Has anyone started a project similar to this?
Thanks.
 
Greif said:
I am looking to extend Microsoft's Data Access Application
Block so it can access Oracle, OLEDB, ODBC in addition to
the default SQL Server.
Click to expand...

Check out the Data Access Block workspace on GotDotNet.com. The Version 3.0
of the DAAB that they have released there does just what you are proposing.

Hope that helps,

John Beyer
 
I just finished writing one for Oracle and SQL Server.
I used Interfaces.
========================================================

For example:

Public Overloads Shared Function ExecuteNonQuery(ByVal connection As
IDbConnection, ByVal commandType As CommandType, ByVal commandText As
String) As Integer
Return ExecuteNonQuery(connection, commandType, commandText,
CType(Nothing, IDataParameter()))
End Function

========================================================

My constructor reads the config file to get the connection string and type
of database (Oracle or SQL Server)

Shared Sub New()
mDBType = ConfigurationSettings.AppSettings("DBType")
mConnStr = ConfigurationSettings.AppSettings("ConnectionString")
End Sub
========================================================

In a handful of methods I simply used the config file entry and returned the
appropriate type of object:

Public Shared Function CreateCommand() As IDbCommand
If mDBType = "SQL Server" Then
Return New SqlCommand
ElseIf mDBType = "Oracle" Then
Return New OracleCommand
ElseIf mDBType = "OLEDB" Then
Return New OleDbCommand
End If
End Function
 
Joe Fallon said:
I just finished writing one for Oracle and SQL Server.
I used Interfaces.
========================================================

For example:

Public Overloads Shared Function ExecuteNonQuery(ByVal connection As
IDbConnection, ByVal commandType As CommandType, ByVal commandText As
String) As Integer
Return ExecuteNonQuery(connection, commandType, commandText,
CType(Nothing, IDataParameter()))
End Function

========================================================

My constructor reads the config file to get the connection string and type
of database (Oracle or SQL Server)

Shared Sub New()
mDBType = ConfigurationSettings.AppSettings("DBType")
mConnStr = ConfigurationSettings.AppSettings("ConnectionString")
End Sub
========================================================

In a handful of methods I simply used the config file entry and returned the
appropriate type of object:

Public Shared Function CreateCommand() As IDbCommand
If mDBType = "SQL Server" Then
Return New SqlCommand
ElseIf mDBType = "Oracle" Then
Return New OracleCommand
ElseIf mDBType = "OLEDB" Then
Return New OleDbCommand
End If
End Function
Click to expand...

hey liked the code
though I could add the following

http://www.noop.nl/articles/Asynchronous_Data_Access.htm

I could you post the
complete listing of your code ?

thanks
Adlai
 
1. I read that article. Very interesting. I decided to omit that
functionality for now since I don't need it yet.

2. I am happy to share the basic ideas but the whole code block was a lot of
work and I am not at liberty to share the whole thing. Sorry. Post any
specific question and if I have an answer I will let you know.
 
Back
Top