your primary concerns with ado.net are connections, commands, readers and transactions.
connections: IDbConnection: open, close and create transactions
commands: IDbCommand: the sql statements. use parametrized querys. there is not excuse for injected sql.
readers: IDataReader: when you read data from the database it's loaded into the data reader. from there you load the data into DataSets, DataTables, or your own POCOs (plain old compiled objects).
I have an FAQ which details an approach to using ado.net within asp.net. some of the concepts carry over to desktop applications. the link is in my signature below.
There are also a number of 3rd party frameworks that ease the use of data access. all of them are built on top of ado.net.
MS DataAccess is designed to execute stored procedures (or dynamic sql) and uses DataSets as the primary data structure within your code.
MS recently released another data access model which mirrors php's data access api.
then you get into ORM (object relational mappers)
the big 3 are
Nhibernate (oss)
Castle.ActiveRecord (oss)
MS Entity Framework
Solution Designs, LLBL Gen Pro ($)
you may also read about Linq2Sql. that technology was replaced in favor of Entity Framework.
Check out the Microsoft Enterprise Library. It has lots of cool stuff in it but, at this point, you'll be interested in the Data Access Application Block.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.