MS Data Access App. Block

  • Thread starter Thread starter Jeremy Cowles
  • Start date Start date
J

Jeremy Cowles

Has anyone used the Data Access Application Block from Microsoft? I have
read good things about it, and my current solution is a bit rickety. I am
either going to fix the holes in my data access layer, or I am going to
implement the DAAB.

What I want to avoid is implementing a new solution that I will be
constantly patching... or something that I can't fix because I don't know
how it was written. So here are my questions:

1. Is the DAAB worth while (in terms of time saved, and overall usefulness)
?
2. Is it written in such a way that I (of average ADO skill) will be able to
extend, or fix it if needed?
3. Are there any issues with deployment?

I know I can answer these questions myself, but I want to know how other
people feel about it too.

Thanks,
Jeremy
 
Hi,

I use the DAAB extensively and have found it to be well designed and very
useful. I have build a sample N-Tier ASP.NET application in which the Data
Access Layer uses the DAAB. Source code and live sample is available from
http://www.ntiergen.net/samples/contacts

HTH,
Gavin Joyce
www.gavinjoyce.com

--
___________________________________________________________
nTierGen.NET Code Generator - http://www.nTierGen.NET/

Stored Procedures (Get, GetPaged, Insert, Update, Delete)
Data Access Layer - C#
Business Rules Layer - C# & VB.NET
Strongly-Typed DataSets - C#
Web Services - C#
___________________________________________________________
 
Jeremy Cowles said:
Has anyone used the Data Access Application Block from Microsoft? I have
read good things about it, and my current solution is a bit rickety. I am
either going to fix the holes in my data access layer, or I am going to
implement the DAAB.

What I want to avoid is implementing a new solution that I will be
constantly patching... or something that I can't fix because I don't know
how it was written. So here are my questions:

1. Is the DAAB worth while (in terms of time saved, and overall usefulness)
?
Click to expand...
Yes. Be sure to get the latest one. It supports strongly-typed datasets.
2. Is it written in such a way that I (of average ADO skill) will be able to
extend, or fix it if needed?
Click to expand...
Yes. Right off the bat I would kill all the overloads that don't pass in an
open connection. That will simplify things a bit. You can extend it from
there. I would consider putting your Data Access Layer in front of the
SQLHelper. I think of the SQLHelper as a "Data Operations Layer".

eg
class DAL
private shared function GetConnection() as SQLConnection

end function


public shared sub UpdateProduct(ProductID as Integer, Name as string ...)
dim con as SQLConnection = GetConnection()
try
SQLHelper.ExecuteNonQuery(CommandType.Text, con, _
"update product set Name = @Name ... where ProductID = ProductID", _
new SQLParameter("@Name",Name), _
..., _
new SQLParameter("@ProductID",ProductID))
finally
con.Close()
end try
end sub

public shared function GetProducts() as ds_Products
' where ds_Products is a strongly-typed dataset (or just use a DataSet)
dim con as SQLConnection = GetConnection()
try

...
finally
con.Close()
end try
end class

end class


3. Are there any issues with deployment?
Click to expand...
No. Just add the SQLHelper class to your solution. Then it's yours.

David
 
David Browne said:
Yes. Be sure to get the latest one. It supports strongly-typed datasets.
Click to expand...


I noticed that it supports updating DataSets. Does it have any issues with
updating JOIN'ed tables?

able
Yes. Right off the bat I would kill all the overloads that don't pass in an
open connection. That will simplify things a bit. You can extend it from
there. I would consider putting your Data Access Layer in front of the
SQLHelper. I think of the SQLHelper as a "Data Operations Layer".

eg
Click to expand...

[SNIP]

This is exactly what I was planning. My current solution has several
functions that execute stored procs, and I was just going to replace those
functions. My actual procs are wrapped with VB functions that map exactly
to SQL so I want to leave those in place (as your sample code demo'd).


No. Just add the SQLHelper class to your solution. Then it's yours.
Click to expand...


Thanks!
 
Jeremy Cowles said:
I


I noticed that it supports updating DataSets. Does it have any issues with
updating JOIN'ed tables?
Click to expand...

You'll either need to un-join your tables and load the data into multi-table
datasets,
or code your own DataAdapter logic.

David
 
Back
Top