Dual Data Access Layers

  • Thread starter Thread starter Magnus Karlsson
  • Start date Start date
M

Magnus Karlsson

Hi!

Our project is a multi-layer-application with a
presentation layer, a business layer and a data access
layer. We have developed two data access layers, one for
Access and one for SQL. Both those data layers use the
same namespace OurCompany.OurProductName.DAL. The
customer will only use one of these DAL:s.

1) Both the OLEDB and the SQL-version of the DAL
exists in our solution (same namespace as described
above). This will make these two projects to collide
because it uses the same namespace. Is there any way
to "disable" one project in the solution and let .NET use
the DAL chosen in the references section?

2) The second problem is more complex. Our business
layer has of course a reference to one of the DAL:s. The
only difference between the OLEDB-version and the SQL-
version is the referenced version of the DAL. We would
like to dynamically set, at run-time-state, the reference
to one of the DAL:s and by this way avoid to develop two
versions of the business layer or implement code that
chooses a namespace of our choice. Is this even possible?

Best regards
Magnus
 
Magnus Karlsson said:
Hi!

Our project is a multi-layer-application with a
presentation layer, a business layer and a data access
layer. We have developed two data access layers, one for
Access and one for SQL. Both those data layers use the
same namespace OurCompany.OurProductName.DAL. The
customer will only use one of these DAL:s.

1) Both the OLEDB and the SQL-version of the DAL
exists in our solution (same namespace as described
above). This will make these two projects to collide
because it uses the same namespace. Is there any way
to "disable" one project in the solution and let .NET use
the DAL chosen in the references section?

2) The second problem is more complex. Our business
layer has of course a reference to one of the DAL:s. The
only difference between the OLEDB-version and the SQL-
version is the referenced version of the DAL. We would
like to dynamically set, at run-time-state, the reference
to one of the DAL:s and by this way avoid to develop two
versions of the business layer or implement code that
chooses a namespace of our choice. Is this even possible?


You don't want to give two different types the same name.

You need to use inheritance or interfaces to interchange your 2 DAL's


Something like the code below. It uses a MustInherit base class (abstract
in C#), and 2 concrete subclasses. One for each provider. Plus it uses a
factory method, GetDAL, to create the appropriate DAL subtype. In your
applicatin code, you just bind to the DAL object. If you need to you can
occasionally downcast the DAL to the appropriate subtype for special
processing.

David



Public MustInherit Class DAL

Public Enum ProviderEnum
SQL
ACCESS
End Enum
Public MustOverride Function GetMyTable() As DataSet
Public MustOverride Function UpdateMyTable() As DataSet
Public Shared Function GetDAL(ByVal ConnectString As String, ByVal
Provider As ProviderEnum)
Select Case Provider
Case ProviderEnum.ACCESS
Return New DAL_Access(ConnectString)
Case ProviderEnum.SQL
Return New DAL_SQL(ConnectString)
Case Else
Throw New NotImplementedException(Provider.ToString)
End Select

End Function
End Class

Public Class DAL_SQL
Inherits DAL

Public Sub New(ByVal ConnectString As String)

End Sub
Public Overrides Function GetMyTable() As DataSet
' do SQL stuff
End Function

Public Overrides Function UpdateMyTable() As System.Data.DataSet
' do SQL stuff
End Function
End Class
Public Class DAL_Access
Inherits DAL

Public Sub New(ByVal ConnectString As String)

End Sub
Public Overrides Function GetMyTable() As DataSet
' do Access stuff
End Function

Public Overrides Function UpdateMyTable() As System.Data.DataSet
' do Access stuff
End Function
 
Yes, basically you must insert a level of indirection for your business
layer to use so that it is always interacting with the same interfaces.

I have an application that loads its DAL dynamically depending on a setting
in the app.config.

Consider this design,

User ---> Business ---> Data Access Abstraction Layer (DAAL)
|
+ SQL DAL
+ OLEDB DAL

Also, look into the Factory design pattern which your DAAL should use to
instantiate the correct classes from the current loaded DAL.

Jeffrey
 
Back
Top