.NET 2.0 - proper DataTableAdapter use?

[matt]

hello,

i am building a data-driven website in ASP.NET 2.0, using "Visual
Studio 2005 Express Web Edition" (phew!).

w/ 1.1, my i normally have my business objects call a data access
layer. for instance, the "/App_code/Restaurant.cs" object's
insert/update/delete methods will call my
"/App_code/DA/restaurantDA.cs" class' functions. inside of
"restaurantDA.cs" i build up command/connection objects, pass in
params, get back datasets, etc.

however, in 2.0, i see that one can use VS2005's "Add DataSet" designer
to build datatables. this is done via the "/App_Code/foo.xsd" file,
using a wizard -- you point it to your db instance, then point to the
procs you wish to use for populating your tables.

using this method, it would seem one can trim nearly all the typical
verbose SQL data access code, and use instead just two lines:

public static DataTable GetRestaurant(int restaurantID)
{
FooTableAdapters.Restaurants adapter = new
FooTableAdapters.Restaurants();
return adapter.GetRestaurant(restaurantID);
}

....and bam, you now have a datatable in *two lines* of code! now, my
question -- should i?? i have no idea if employing this new wizard tool
in VS2005 is a good idea. i dont know how heavy or light these objects
are compared to the typical verbose SQL code (building up
command/connection/parameter/dataset objects, etc).


can anyone speak to this?


thanks!

 

[David Browne]

hello,

i am building a data-driven website in ASP.NET 2.0, using "Visual
Studio 2005 Express Web Edition" (phew!).

w/ 1.1, my i normally have my business objects call a data access
layer. for instance, the "/App_code/Restaurant.cs" object's
insert/update/delete methods will call my
"/App_code/DA/restaurantDA.cs" class' functions. inside of
"restaurantDA.cs" i build up command/connection objects, pass in
params, get back datasets, etc.

however, in 2.0, i see that one can use VS2005's "Add DataSet" designer
to build datatables. this is done via the "/App_Code/foo.xsd" file,
using a wizard -- you point it to your db instance, then point to the
procs you wish to use for populating your tables.

using this method, it would seem one can trim nearly all the typical
verbose SQL data access code, and use instead just two lines:

public static DataTable GetRestaurant(int restaurantID)
{
FooTableAdapters.Restaurants adapter = new
FooTableAdapters.Restaurants();
return adapter.GetRestaurant(restaurantID);
}

...and bam, you now have a datatable in *two lines* of code! now, my
question -- should i?? i have no idea if employing this new wizard tool
in VS2005 is a good idea. i dont know how heavy or light these objects
are compared to the typical verbose SQL code (building up
command/connection/parameter/dataset objects, etc).


can anyone speak to this?

It's all codegen. Look at the files generated by the DataSet designer. All
of your familiar verbose code is there. You just didn't have to write it.
IMO Table Adapters rock.

David

 

[Sahil Malik [MVP]]

Matt,

As David rightfully said, TableAdapters are simply code generation. However
given the fact that it is one size fits all approach, truthfully the two
lines below call many many more lines of code underneath (or atleast work
with many lines of code).

Is that appropriate? Well totally depends on your situation. Like any OSFA
(one size fits all) approach, it won't be the best, but it'll be quick &
cheap to develop.

This comes back to the software triangle - GOOD CHEAP FAST - You can have
only two of those, take your pick

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx