extending Data Access Application Block

[ThatGuy]

We're looking at the Data Access Application Block (DAAB), and while it is
nice and clean, it also lacks some functionality that we want. The biggest
missing piece, in my opinion, is the lack of connection string management.

Other people must have modified the DAAB to meet similar needs. Has anyone
posted a modified/extended version of the DAAB? What other features have
people added to their custom data access helpers?

(Perhaps connection string management will be addressed by the configuration
application block mentioned a couple threads back?)

[Kirk Allen Evans]

The way I recommend to use it is to provide our yown data access layer that
manage interaction with the DAAB.

UI -> Business Objects -> Data Layer -> DAAB -> SQL Server

Your separate DAL is responsible for knowing what SQL statement to issue,
what the stored proc names are, what parameters are necessary for the stored
proc, and the appropriate connection string(s). This buffers so that the
business objects do not maintain this information (without this layer, the
business objects become very aware of the underlying data stores). This
also gives the ability to split data layers to interact with an Oracle Data
Access Application Block, just by specializing classes in the custom Data
Layer (this is somewhat of a red-herring, but a benefit nonetheless).

The biggest argument against calling the DAAB directly from your business
objects is that System.Data.SqlClient.SqlParameter inherits from
MarshalByrefObject. If you try to separate the business layer and data
layer on separate machines, you are going to have a lot of traffic back and
forth to use SqlParameter objects. But you can alleviate this by
controlling access to the DAAB through your custom layer.

A recent project I was part of used the DAAB as a starting block and altered
it significantly to support typed dataset support and connection string
management. This quickly became a problem when one application had multiple
connection strings for different operations, causing the connection string
to be managed by both the business layer and the data layer.

To gain DataSet support, write your own set of classes to support the
relationship management, any XML interaction you need, etc. and resist the
urge to modify the DAAB. This gives you a lot of flexibility as far as
using SQL Server's Diffgram support with SQLXML, creating separate Update,
Insert, and Delete commands for a SqlDataAdapter, and managing the
parameters needed for interaction.

--
Kirk Allen Evans
Author, "XML And ASP.NET", New Riders Publishing
www.xmlandasp.net
http://dotnetweblogs.com/kaevans

"ThatGuy" <nom...@nomail.nomail> wrote in message
news:evRSlSD...@TK2MSFTNGP09.phx.gbl...
> Its also missing typed dataset support -- that seems like a pretty big
> omission.
>
> "ThatGuy" <nom...@nomail.nomail> wrote in message
> news:OHmBPID3...@TK2MSFTNGP11.phx.gbl...

[Paul Speranza]

I have modified both the Oracle and SQL Server versions from the Nile sample
app to support returning DataTables. All I did was copy the DataSet methods
and changed references from DataSet to DataTable. STill testing it but it
seems ok so far. Let me know if you want the code.

Paul Speranza

"ThatGuy" <nom...@nomail.nomail> wrote in message
news:OHmBPID3...@TK2MSFTNGP11.phx.gbl...

[TPS]

Kirk,
Great informative response.

Thanks for the info.

--

T.

[ThatGuy]

Thanks Kirk. You have some excellent points.

I have a decent number of data access layer (DAL) components. I wanted to
use the DAAB and still keep the connection string manangment isolated from
each individual DAL component. After your feedback, instead of putting this
into the DAAB, I think I will create a base data access layer component that
will handle the connections strings -- that way the code won't be duplicated
everywhere.

As far as typed datasets, I found post from someone that was getting generic
datasets back from the DAAB and then merging them into a typed dataset.
This seems a little over complicated for me. I think I will be modifying
the DAAB to support typed datasets -- I think it was a pretty big oversite.
It will be a simple change, just an overload or two that takes a dataset
passed in rather than creating and returning a new dataset on each call.

Thanks again for your feedback!

"Kirk Allen Evans" <kae...@nospamxmlandasp.net> wrote in message
news:OtJrWCE...@TK2MSFTNGP11.phx.gbl...

[ThatGuy]

That's a great idea. I will have to check out the Nile code as well to see
if it would be better to go that direction.

"Paul Speranza" <paulsp...@hotmail.com> wrote in message
news:ufV7ijN3...@TK2MSFTNGP09.phx.gbl...

[Keith]

YOu could create a common class and make a generic
function to take a "strSQL" statement and return only the
data you need via the datareader to a dataset, then set
the binding for the control(s) that will use it. you can
use a single dataset or multiple. i use that alot and it
works very very well.
If you want the snippet let me know i ll give it to ya.

>.
>

[Don McNamara]

Keith,

Can you send me that code (or just post it here?)

Thanks,
Don McNamara

"Keith" <nt...@hotmail.com> wrote in message
news:006d01c2dfb9$784fe180$2f01...@phx.gbl...