Generated code - Databinding, Adapter

Preface

Databinding is a .NET feature which can drastically increase productivity. It is also a technique that works both with single objects and properties as well with collections with objects. To be able to use databinding with the generated code, both the entity objects and the EntityCollection<T>s are made databinding aware. This section describes the databinding functionality available through the generated code for Windows Forms, WPF and 1-way ASP.NET databinding.

Implemented functionality

This section briefly discusses the implemented functionality in the various classes of the generated code you will use with databinding.

Entity classes
All entity classes implement the following databinding aware interfaces:

• INotifyPropertyChanged.
• IEditableObject
• IDataErrorInfo

Typed views and typed lists
Typed View and Typed List objects are generated as classes deriving from DataTable, and because the DataTable already is equipped with all the databinding functionality necessary, you can bind a Typed View or Typed List without trouble to a datagrid or to a set of GUI controls.

EntityCollection<T> instances
The EntityCollection<T> class (generic and non-generic) implement the IListSource interface. This means that bound controls will request from the EntityCollection<T> object a separate object they can bind to. An EntityCollection<T> class instance returns its DefaultView for this. This means that when you set a control's DataSource property to an EntityCollection<T> instance, the collection won't bind directly to the control though it will bind to the control through an EntityView2<T> instance, the object returned by the collection's DefaultView.

This also means that if you create your own EntityView2<T> instance on a given EntityCollection<T>, you can bind that EntityView2<T> to the control instead, to have a subset of the data in an EntityCollection<T> visible in the control. This is similar to how DataTable and DataView work hand in hand. All actions taken on the data, including e.g. creating new entities in a grid, are performed on the EntityCollection<T> related to the bound EntityView2<T>. For more details, please see: Generated code - using the EntityView2 class for details.

EntityView2<T> implements all useful properties and methods of IBindingList. Among these features are: sorting in grids, making the EntityView2<T> read-only, do not allow addition, removal of rows. It furthermore implements ITypedList to make sure only the useful fields/properties of the entity types are visible in the bound control.

Design time databinding support in Visual Studio.NET

To setup databinding at design time, it's recommended you use the Data sources feature in Visual Studio.NET. Create a Data Source based on an entity type in the generated code, e.g. CustomerEntity. Setup databinding using that data source, e.g. through dragging a BindingSource onto your form. When you set the DataSource property of that BindingSource to the Data Source you created of the entity type, you can design the control bound to the BindingSource. At runtime, set the DataSource property of the BindingSource instance to a fetched EntityCollection<T> instance. This will make sure the data shows up in the control bound to the BindingSource.

For ASP.NET webforms and 2-way databinding and how to setup this databinding using DataSourceControls, please see: Generated code - Databinding with ASP.NET WebForms

Databinding and Data Scopes

To fully utilize databinding with the runtime framework elements and to write as less code as possible, it's recommended to use the Data Scopes feature. Data Scopes de-couple the code for fetching and persisting bound data from the UI and take care of much of the necessary 'plumbing'. See the Data Scopes section for more information about how to utilize them with your databinding code.

Databinding and inheritance

When using an inheritance hierarchy, you typically have subtypes with more fields than the supertypes. As LLBLGen Pro supports polymorphic fetches, it can be in an EntityCollection<T>, entities of various types (all from the same inheritance hierarchy) are found. If several of these entity types have fields not found in their super-types or siblings in the hierarchy, what will show up in a grid if such a collection is bound to that grid?

LLBLGen Pro will provide to the bound control properties for all fields which are found in the type set for the collection. For example, if you've a hierarchy like Employee <- Manager <- BoardMember, and you fetch all Manager entities into an EntityCollection<ManagerEntity>. It can be that in that case, one or more of the Manager entities in the collection are actually of type BoardMember, due to Polymorphic Fetching. BoardMember entities have for example a field called CompanyCarId, and Manager entities don't have that field. Binding the fetched EntityCollection<T> to a grid, only the fields from the Manager entity will show up in the grid, as that's the type set for the EntityCollection<T> bound.