As a supplement to my talks at the Central Penn .NET User's group and the .NET Valley User's group this month, I am providing some information on using the ObjectDataSource control.
ObjectDataSource Summary:
The ObjectDataSource is made for use in n-Tier applications, and you will want to create at least a DAL (data access layer) and you will most likely have a BLL (business logic layer) as well. The ObjectDataSource provides a nice layer of abstraction between the UI and the data storage, whereas the SqlDataSource has a standard client/server architecture with direct access between it and the data store.
The ObjectDataSource also provides caching, paging, sorting, data binding and many other handy and useful features.
A Few Notes:
Build your BAL/DLL first, then start mapping the object's methods and properties to the ObjectDataSource. This will make your custom objects more applicable to other apps, which is a good thing when building large systems with reusable components.
Use a Data Mapper pattern. In short, this entails creating an entity class that map its properties to the fields in database tables, and another class for managing/transporting the entity class between the ObjectDataSource and the data access layer/data store. When you use the Data Mapper pattern you will set the DataObjectTypeName property of the ObjectDataSource to the entity class and pass the entity class as an argument to your Insert/Update/Delete methods. It's easier and more maintainable than having to pass several dozen arguments (aka, each field as an argument) to your Insert or Update methods.
You can also use just a data manager class with methods that map to CRUD operations.
Or, you can use the ObjectDataSource with a strongly typed DataSet.
Tips/Tricks/Gotchas:
While you will use the DataObjectType name to assign your entity class to the ObjectDataSource, you will use the TypeName property to assign your manager class or to bind to a strongly typed dataset.
Match the field names of your bound controls to your custom object property names. The ObjectDataSource uses Reflection to figure out the mapping between the names so they need to be named the same.
The ObjectDataSource cannot call remote objects directly (BAL/DLL objects on another machine). You'll need to create a wrapper locally and use remoting, web services or the like to make the connection.
For one way inserts, such as a data entry web page, consider not even using the ObjectDataSource. You can just as easily create the ADO.NET code yourself. Also, the configuration wizard will not allow you to move to the next step without choosing a select method.
Use caching! Appropriately, of course. Static data such as product, employee, states, countries, etc... are great types of data to be cached. The ObjectDataSource takes advantage of caching just as much as the next control.
Moving from the SqlDataSource? It's fairly easy in most cases.
- Add your custom class/strongly typed DataSet to your project.
- Open your .aspx page and delete the SqlDataSource control
- Add the ObjectDataSource control to the page and use the Configure smart tag to connect to your custom class/DataSet
- Reset the DataSourceId property of the bound control(s) such as the GridView or Repeater.
- If it asks about Refreshing, say No - unless you need to, but you probably don't.
- Your mileage may vary depending on the exact circumstances but I've found it easily in most situations to quickly make the switch.
ObjectDataSource Resources:
MSDN Documentation on ObjectDS
Code Project's Comprehensive Guide to the ObjectDataSource
Manuel Abadia's great 3 Part series
ASP.NET's ObjectDataSource Tutorial
