Web Forms Data Binding in C#

Encoding PDF-417 2d barcode in C# Web Forms Data Binding

Web Forms data binding in ASP.NET 2.0 is bidirectional, meaning that data is copied from the data source into the web form s controls, and then from those controls back into the data source (either a preexisting instance, or a newly created instance) on a postback. This is powerful, as it simplifies both the display and update of data. Unfortunately, the data source controls provided with ASP.NET are not designed to work with objects that contain business logic meaning that they aren t useful when working with CSLA .NET business objects. To overcome this limitation, the CslaDataSource control is an ASP.NET data source control that is designed to work with objects containing business logic. This control allows the full use of Web Forms data binding with rich business objects. Data source controls in ASP.NET have two major areas of functionality: runtime and design time. Runtime functionality is the actual data binding implementation it copies data from the data source to the controls and back again. Design time functionality exists to support Visual Studio 2005, allowing developers to graphically create web pages using common controls like the DataGridView and DetailsView when they are bound to the data source control. It turns out that implementing runtime functionality is relatively straightforward, but providing design time functionality is more complex. Table 5-6 lists the classes required to implement the CslaDataSource control s runtime and design time support.

Csla.Web.CslaDataSource Csla.Web.CslaDataSourceView Csla.Web.CslaDataSourceDesigner Csla.Web.CslaDesignerDataSourceView Csla.Web.ObjectSchema Csla.Web.ObjectViewSchema

The data source control itself; this is directly used by the UI developer Provides the actual implementation of data binding for CslaDataSource The Visual Studio designer for CslaDataSource Provides schema information and sample data for the designer The schema object for a business object, responsible for returning an instance of ObjectViewSchema Provides actual information about a business object; specifically information about all the business object s bindable properties Maintains information about a specific field in the object schema

The detailed design issues around building an ASP.NET data source control are outside the scope of this book. Nonetheless, I ll walk quickly through the code in these classes to call out the highlights of the implementation. First, though, it is helpful to understand the relationship between all these classes. Figure 5-7 shows how they are related.

The UI developer drags a CslaDataSource control onto a Web Form and interacts with it. While in Visual Studio, all that interaction is actually coordinated by CslaDataSourceDesigner, though in reality all the hard work is done by CslaDesignerDataSourceView.

When a control such as GridView is bound to the CslaDataSource, it requests schema information about the data source. This schema information is created and returned by the ObjectSchema, ObjectViewSchema, and ObjectFieldInfo objects. Finally, at runtime, the web form interacts with CslaDataSource to perform the actual data binding. All the hard work is actually handled by CslaDataSourceView, an instance of which is managed by the CslaDataSource control.

The CslaDataSource class is the primary entry point at both design time and runtime. This is the object that a developer places on his web form when building a page. But really it is primarily a coordinator that connects all the pieces of the data source control together. This starts with the declaration of the class itself, in which a [Designer()] attribute is used to connect CslaDataSource to CslaDataSourceDesigner within Visual Studio: [Designer(typeof(Csla.Web.Design.CslaDataSourceDesigner))] [ToolboxData("<{0}:CslaDataSource runat=\"server\"></{0}:CslaDataSource>")] public class CslaDataSource : DataSourceControl { } Within the class itself, the code is largely concerned with providing the ASP.NET data binding infrastructure with a reference to the CslaDataSourceView object, and relaying events from the CslaDataSourceView back to the UI. Basically, CslaDataSource is merely a go-between at runtime, and a way of finding CslaDataSourceDesigner at design time. The only bit of functionality that a UI developer will see is that CslaDataSource declares and raises four events. The UI developer must respond to these events to provide the interaction with the business object. Table 5-7 lists the events. Table 5-7. Events Raised by the CslaDataSource Control