Presenter: Rocky Lhotka
Code: http://www.lhotka.net
This discussion contains information about creating custom data source controls. Before diving into the concepts involved, lets first consider a justification for such development. This is provided in the form of an analysis of the two most commonly used controls that are available for that purpose:
SqlDataSource
The SqlDataSource object allows developers to retrieve data from a database directly and use data-binding to display and edit the data inside of web or windows forms. However, this is really only useful in 2-tier applications and leads to a poor architecture. I find the SqlDataSource control to be most useful in prototyping.
ObjectDataSource
The ObjectDataSource, while vastly superior to the SqlDataSource control, is still quite restrictive in several ways. It requires the presence of a default public constructor and restricts the use of read-only properties in the objects with which it can interact. Having a default public constructor weakens the application of a factory pattern for object creation, and the lack of support for read-only properties weakens the encapsulation of the objects. Furthermore, the ObjectDataSource control was originally called the DataSetDataSource control and was originally intended exclusively for the purpose of connecting to data sets. The fact that it also works for custom object types is more of an accidental side-effect than a planned purpose. Another weakness of the ObjectDataSource control is that it uses reflection to invoke methods upon your custom objects at run-time based upon string names of those methods that were configured at design-time. However, this provides no compile-time warning or errors in the case that a method name was typed into the designer or markup incorrectly or in the case that the method name is changed.
Base Classes for a custom Data Source
There are four base classes that are important when implementing a custom data source control:
- DataSourceControl
- DataSourceView
- DataSourceDesigner
- DesignerDataSourceView
There are also three interfaces that need to be implemented:
- IDataSourceSchema
- IDataSourceViewSchema
- IDataSourceFieldSchema
| DataSource |
DataSourceView |
|
| DataSourceDesigner |
DesignerDatasourceView |
|
| ObjectSchema |
ObjectViewSchema |
ObjectFieldInfo |
| Configuration |
|
|
Debugging Custom Data Source Controls
The debugging story for custom control development is a little different from the typical debugging experience because the runtime and design-time execution is actually happening within Visual Studio itself. Typically an external executable or a web hosting service such as IIS would host the code. However, for a custom control it is Visual Studio that is executing the designer and run-time code and as such the debugging story needs to change slightly. The way in which we debug custom controls in Visual Studio is to start a second instance that will be the test host and then attach to the process of that Visual Studio instance with the main instance from which we will perform the debugging. Now breakpoints will be hit in the first instance of Visual Studio as the second instance of Visual Studio executes the code within the custom control.
Run-time Support
The base DataSourceControl class
The base class to use for a custom data source control is System.Web.UI.DataSourceControl.
The base DataSourceView class
The data source view derivation actually performs the bulk of the work for the control. This class is derived from the System.Web.UI.DataSourceView. To implement a derived data source view class, you must override the ExecuteSelect method from the base DataSourceView class. When a data-bound control is rendering, for example a GridView, the control realizes that it does not have a data source. However, it realizes that a data source control is configured and asks the data source control for some data. This raises the ExecuteSelect method on the derived DataSourceView class. It is in this method that the data for the source is read and returned. Additional properties such as row count, for paging, are set during the method. The assumption is that once the ExecuteSelect method has completed, the data-bound control that originally made the request will be able to commence with data binding. Other methods such as ExecuteInsert need to be overridden as appropriate for the data source control, based upon whether or not the control support such actions.
Design-time Support
The DataSourceDesigner base class
The base class DataSourceDesigner is a fairly thin class that essentially specifies the view for the data source designer as well as a couple of extra information attributes that are used in the design-time experience.
The DesignerDataSourceView base class
The DesignerDataSourceView base class is used to derive the view class that will provide the bulk of the design-time support for your custom control. It is from within your designer data source view class that you will return properties such as the schema or list of fields that describe the currently configured data source for the control. This is a complex concept to visualize right away, however consider that the ObjectDataSource control uses reflection to determine the list of fields that exist upon the object type that is currently configured within the control. It is this list of fields that is used to populate the dialogs within the design-time view of the control. Other methods such as GetDesignTimeData should be overridden to, in that example, return the data that is used to populate the design-time view of the control. In the case of the grid-view control (not a data source but a similar paradigm) this is the sample data that is displayed that looks like "abc" in each of several sample rows.