The TableAdapters are nice (ie, in the DataSet), but far more useful when
you can separate out the definition from the data access, which requires
..NET Framework 3.5/Visual Studio 2008. I generall do not head this
direction, but I am not against it, as it performs rather nicely.
If you go the database route, I would code as stored procedures. I know
there are others who will disagree with me on this, but it is easier, esp.
when learning, to secure sprocs than it is to secure code in objects served
up by a factory method, etc.
The stored procedure also acts as an abstraction as long as you are using a
relational server that allows sprocs, as you can change the driver/provider
and still query. This is not always true in practice, although it is in
theory (Oracle, for example, requires passing in a structure for output when
using the OracleClient objects).
One thing the abstraction does allow, however, is altering schema underneath
the sprocs, so you can version your database without impacting application
logic.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box!
|
*************************************************
"Andy B" <a_*****@sbcglobal.netwrote in message
news:uq**************@TK2MSFTNGP02.phx.gbl...
Where would probably be the best place for queries to the database? in the
db as stroed procs or in the dataSet.
