ADO.Net TableAdapters and TableAdapterManager Code Camp 2008 Emmet Gray

Introduction Strongly-typed DataSets Based upon DataSet and DataTable classes Based upon DataSet and DataTable classes Wizard based (no need to hand code) Wizard based (no need to hand code) Graphical view of the data Graphical view of the dataBenefits Design-time type checking Design-time type checking Intellisense Intellisense Slight performance increase* Slight performance increase*

Strongly-Typed DataSet Disadvantages Severe code bloat* Severe code bloat* Is often incorrectly used as a substitute for true n-tier “data access layer” Is often incorrectly used as a substitute for true n-tier “data access layer” Use of wizard may cause you to overlook other options such as stored procedures Use of wizard may cause you to overlook other options such as stored procedures * Performance increases may be overshadowed by code bloat

TableAdapter Strongly-typed version of the DataAdapter class The typical way to get data in/out of a strongly-typed DataSet The typical way to get data in/out of a strongly-typed DataSet One “DataAdapter” per table One “DataAdapter” per table Has traditional Fill() and Update() methods Has traditional Fill() and Update() methods Can be expanded with additional methods Can be expanded with additional methods Concepts similar to that of stored procedures Concepts similar to that of stored procedures All queries located in one place All queries located in one place

TableAdapter Disadvantages Tied to the current data provider (i.e. SQL Server) To make a program database “agnostic” you would: Build the DataSet as usual Build the DataSet as usual Remove all TableAdapters Remove all TableAdapters Use the “Data Provider Factory” Use the “Data Provider Factory”

Schema Based All queries in a TableAdapter must return rows based upon the schema associated with the strongly-typed DataTable Joins are allows for filtering (but only columns in the base table are allowed) Joins are allows for filtering (but only columns in the base table are allowed) Exception for scalar queries (that return a single value) Exception for scalar queries (that return a single value) Supports parameterized queries Supports parameterized queries

Queries So how do I handle custom queries that return a different schema? Create a new TableAdapter! Create a new TableAdapter! Also creates a new strongly-typed DataTable Also creates a new strongly-typed DataTable Update() methods Automatically creates the “CommandBuilder” equivalent Insert, Update, Delete commands Automatically creates the “CommandBuilder” equivalent Insert, Update, Delete commands

Database Integrity Constraints upon the data Unique / Primary key Unique / Primary key Foreign Key Foreign KeyRelationships Strongly-typed DataSets support relationships Strongly-typed DataSets support relationships Enforces relationships at run-time Enforces relationships at run-time Detects problems prior to saving to back-end database Detects problems prior to saving to back-end database

Saving the data TableAdapter.Update() method Scans the rows for changes and sends the changes to the back-end database Scans the rows for changes and sends the changes to the back-end database How does the TableAdapter handle updates for queries based upon joins? Poorly… Poorly… You’re are forced to write the update logic by hand You’re are forced to write the update logic by hand

Database Integrity Revisited Since strongly-typed DataSets support relationships, I’m good to go… right? That’s true for your locally cached version of the data That’s true for your locally cached version of the data But you must make sure you update the tables in the back-end database in the correct order! But you must make sure you update the tables in the back-end database in the correct order! Particularly important in foreign-key relationship Particularly important in foreign-key relationship

TableAdapterManager TableAdapterManager New to VS2008 New to VS2008 Automatically scans the relationships and builds an UpdateAll() method that updates the tables in the correct order Automatically scans the relationships and builds an UpdateAll() method that updates the tables in the correct order Not really based upon a “base class” Not really based upon a “base class” Not tied to newer.Net Framework v3.x Not tied to newer.Net Framework v3.x

End Notes TableAdapter Based upon the associated schema of the strongly-typed DataTable Based upon the associated schema of the strongly-typed DataTable Handy place to keep all your queries Handy place to keep all your queries May not be suitable for all ocasions May not be suitable for all ocasionsTableAdapterManager New component to solve the problem of updating the back-end database tables in the correct order New component to solve the problem of updating the back-end database tables in the correct order