The design-time support for databinding in the new Windows Forms (WinForms) .NET
Out of Process (OOP) Designer is different from the Framework Designer. The
WinForms OOP Designer has a new and easier approach for hooking up data sources,
focusing on Object Data Sources to support .NET based object relational
mapper
technologies (like the latest version of Entity Framework Core – EF
Core for short) which the WinForms team
recommends as a successor for Typed DataSets. This new approach was due to the
completely different architecture of the new WinForms OOP Designer, which we
have discussed in the previous blog
post.
If you haven’t read it yet, you should do so first, as it is essential for a
better understanding of this post.
Why is the Data Source Tool Window unavailable in .NET projects?
Essential to databinding in WinForms .NET Framework is the Data Source Provider
Service. This service runs in Visual Studio, and its responsibilities are as
follows:
It generates and maintains Typed DataSets by connecting to a database data
source (for example Microsoft SQL Server or Oracle DB Server).
It detects types which are designed to act either as Typed DataSet Data
Sources or Object Data Sources.
It identifies potential Object Data Sources and sets those up in the
project.
It discovers legacy (for example SOAP-based) web services and sets them up
in a way so they can act as data sources.
It provides the UI functionality for the Data Source Tool Window in .NET
Framework for WPF and WinForms applications. It also provides the UI Wizard
to add new or maintain existing SQL Server connected data sources.
As of today, the Data Source Provider Service only works in the context of
Visual Studio, which means it can only type-resolve .NET Framework assemblies
and types. For .NET in its current version, the Data Source Provider Service is
not able to retrieve the necessary type information as it would need to operate
on the .NET Server Side (the
DesignToolsServer).
This is the reason that the UI stacks which used to rely on the Data Source
Provider Service (WinForms, WPF) need to come up with alternatives for setting
up new data sources and at the same time support legacy scenarios as well as
possible. Providing feasible migration options, so that data access and
databinding technologies can be migrated Form by Form, with both data source
binding approaches (Typed DataSets and new ORMs based on Object Data Sources)
present over a period of time, was the main driver for the new databinding
functionality.
Working with legacy Typed DataSets in the OOP Designer
To decouple WinForms from the dependency to the Data Source Provider Service,
there is now a new and quicker way to hook up new Object Data Sources.
That said, existing Typed DataSets definitions copied from Framework projects
can – with some limitations – be consumed by the OOP Designer even without that
service present. This means, data-bound Forms or UserControls using Typed
DataSets can be opened, and the Design Binding Picker (the drop-down editor in
the Property Browser to pick data sources for binding) will continue to provide
the necessary functionality to define the databinding of individual properties
of controls. At this time, though, no new Typed DataSets can be generated in
the context of a WinForms .NET application. It is also not possible, to
interactively update the schema for a Typed DataSet by querying the schema of
the assigned database. Necessary components (DataSet and for assigning the
data at runtime tablenameTableAdapter) to add a new binding definition can,
however, be added from the toolbox and hooked up manually – which means
maintaining legacy data-bound forms based on Typed Data Sets in .NET WinForms
projects is generally supported.
The following animated gif shows the process. Copy the Typed DataSet definition
from your existing Framework project to your new .NET project and see that all
necessary adapters and DataSets automatically appear in the toolbox on
recompile. You see: Clicking the Typed DataSet based data source on the Picker
does only set up the binding if the respective components are present in the
Component Tray.
New Approaches when using Object Data Source Binding
Object Data Sources can, in contrast to Typed Data Sets, get their data through
all different kind of means. One of the most popular alternatives, which is a
great replacement for old-fashioned Typed DataSets, is Entity Framework Core (EF
Core for short). Apart from the fact that it has greater performance and a
bigger set of functionalities compared to Typed Data Sets, it also uses a
different approach in dealing with the permanent task of updating and
maintaining a database’s schema. While EF Core can principally be used in the
same way as Typed Datasets, which are generated based on an already existing
database, data objects based on EF Core can take a different more flexible and
more maintenance-friendly approach, which is called Code first.
Code-first in this context
means, the class
definition defines the data structures/schemas, the relations between the
entities (tables), and then the actual database schema is derived from this
class definition: So-called migration-code updates the actual database
definition on the fly. The advantage: The underlying database technologies is
abstracted away: Code-first enables you to generate the schema for many
different database
systems:
SQL Server, SQLite, Oracle Server, In-Memory databases, Cosmos, PostgreSQL,
MySql – you name it!
Let’s consider the following scenario: We build a .NET 6 Windows Forms
application using EF Core code-first with
data classes defined in a dedicated class library. This way, we can reuse the
data layer code in other projects. But – in contrast what you would have done
with Typed DataSets, we are not binding the EF Core data classes directly to the
WinForms UI. The goal is to reduce the business logic code in the actual UI
(Forms/UserControls) and get rid as much as possible of the WinForms typical
“Code Behind” style. For that, we are introducing a set of properties to bind to
yet another Object Data Source, which implements the business logic instead. We
call this the business logic UI-controller class, or UI-controller for
short. And those are the properties, we bind. A few examples:
Instead of setting the window title text of a Form directly in code-behind
in the Form, we have a property in the UI-controller for the windows title.
And that we bind.
A Save button should only be enabled when there actually is something to
save. Instead of enabling or disabling the button in Code-Behind in the
Form, we are introducing for example a `SaveButtonEnabled` property in the
UI-controller, which we then bind against the `Enabled` property of the
button.
We can even utilize a concept which originated from WPF and is called
Command
Binding.
It’s suitable for elements like ToolStripItems (and the derived
components ToolStripButton, ToolStripMenuItem and others) or
Button controls and implemented via the ICommand interface: When the
user clicks on such a button in the WinForms UI, and the command property of
that button is bound to a respective property in the UI-controller class,
the command executes the underlying business code in the business class
logic rather than in some Click event code-behind.
A UI-controller class would look something like this:
Using a combination of data classes (which represent the Database) and
UI-controller(s) in this way as Object Data Sources has some advantages:
Business logic reuse: The business logic is defined by business object
(data source) classes independently of the UI. This means they can be reused
in other scenarios. The same business objects which are used in a WinForms
application could also be used for example in a Maui .NET mobile
application.
Unit tests: Since the business logic doesn’t include any specific
UI-stack dependencies, it can be unit tested way more easily. That is a big
advantage over the WinForms typical code-behind approach.
View model/UI Controller support: Object Data Source classes can – or
rather should – implement the `INotifyPropertyChanged` Interface. This
enables data sources to act as UI-Controller classes (or View Models), which
make them suitable to be reused in other UI Stacks.
Note: Although the binding infrastructure in WinForms is comparatively powerful,
it doesn’t have the flexibility of XAML-based binding which you might know from
WPF, UWP or Maui. For WinForms, you will most likely always be ending up with
some Code-Behind code to support UI-Controller binding scenarios, which are
otherwise difficult to implement just on the model/controller side. But that’s
OK and expected. For a better reusability of code and the ability to write code,
which is testable, it’s still worth the effort. And a migration to this way of
binding can be easily done over time, Form by Form, so it is really feasible and
can be planned for huge LOB apps. On top, we plan to further support and extend
UI-controller centric scenarios in the .NET
7 time frame for WinForms
projects.
The New Add Object Data Source Dialog
To use a certain class as your Object Data Source, start the binding process as
you previously would:
Open the Design Binding Picker to add a new Object Data Source definition to
your project.
Click on the link Add new Object Data Source to find the type you want to
use as a data source in your project.
Use the Filter field to filter the selection by name. Note that types
which implement the `INotifyPropertyChanged` interface (or derive from
types which are based on that interface) are formatted in bold typeface.
Use the checkboxes in the dialog to include or exclude types, which are not
part of your project, or to control how the types are organized in the list.
The example in the animated GIF below shows how a slightly modified
ToolStripMenuItem component can be bound this way to a Command, and in
addition a DataGridView’s DataSource to a property of a UI-controller
representing a list of customers:
Here you see that adding MainUIController as an Object Data Source and
then binding its Import command to the ImportExternalDataCommand
property automatically led to the adding of the
mainUiControllerBindingSource component: In the Design Binding Picker you
can then pick that component as the actual data source.
History lesson: why BindingSources as mediators and no direct binding?
Adding a BindingSource component for an Object Data Source as a mediator
between the data source and the target control/component is a concept which
WinForms adapted from the early beginning (.NET 2.0 back in 2005). The
BindingSource component acts as the so-called currency manager. Currency
in this context means, the BindingSource component manages which data item
in a list of items is the current one. This way of binding is also done for
scenarios, for which the data source is or provides only one object instance – a
UI-controller or a single data source item for a data entry form for example.
This principle is being kept for backwards compatibility reasons, which means
that any attempt to bind the first property to a newly added (object) data
source will always add a respective BindingSource component to the
component tray. The actual binding will then be hooked up to that
BindingSource component rather than to the data source directly.
Note: It is important to know in this context, that WinForms doesn’t
natively know the concept of type conversion based on the IValueConverter
interface as it is used in WPF, UWP or WinUI. Rather, a conversion during
binding can be done by handling the events, such as Format and Parse,
which are provided by the actual binding instances generated by the designer for
the binding in InitializeComponent. Like this:
public FormMain()
{
InitializeComponent();
// Current version of WinForms Databinding doesn’t allow yet
// IValueConverter, we do this instead:
var totalRevenueBinding = _totalRevenueTextBox.DataBindings[0];
// ConvertTo, here Decimal to String as an example:
totalRevenueBinding.Format += (sender, eventArgs) =>
{
if (eventArgs.DesiredType != typeof(string))
{
return;
}
eventArgs.Value = ((decimal)eventArgs.Value!).ToString();
};
.
.
.
In this sample code we are assuming there is only one DataSource/Control binding
for a TextBox named _totalRevenueTextBox. We’re getting its Binding
definition and wire up to its Format event, where the actual conversion is
then handled at runtime.
Improvements to Advanced Databinding
We also made improvements to the Advanced Databinding Editor. You use the
Advanced Databinding Editor for all properties which are not listed directly
under Data Binding in the Property Browser. This dialog now shows what component or
control you are binding to. It also shows what exact type of that control or
component you are editing. Also, rather than picking the binding trigger from a
drop-down list, you can now directly set that by clicking radio buttons, which
is quicker and more accessible.
The Advanced Databinding Dialog now allows to set up another binding scenario:
Sometimes it’s necessary that you define a whole property path in complex
binding scenarios – which are scenarios, where you are binding to a list rather
than to a single object instance. In those cases, the correlating
BindingPath and BindingField of the Binding’s instance
BindingMemberInfo property can now easily be set in the Advanced Databinding
Editor by entering the whole path in the Path entry field. If this field gets
the focus, Path and Field are merged, and you can edit the property path as
a whole. When that entry field later loses the focus again, Path and Field
are separated in the same way as they would show up if you’d queried them at
runtime through the Binding’s correlating BindingMemberInfo property:
Summary and key takeaways
Databinding in WinForms .NET is focused on Object Data Binding. We encourage
developers to explore modern ORM technologies like Entity Framework Core,
which can be used in their latest versions in contrast to .NET
Framework.
Databinding of legacy technologies (Typed DataSets) is still supported,
albeit with some limitations. Typed DataSet definitions can be copied from
Framework projects, but new Typed DataSets cannot be created in .NET
projects, nor can their schemas interactively be changed.
Tip: Old and new database mapping technologies can coexist in a WinForms project,
so there is a feasible way to gradually migrate the underlying data layer
technologies, one Form at a time.
Object Data Sources are defined for the project through the Design Binding
Picker in the Property Browser by clicking on the Add New Object Data
Source link. The Data Source Provider Service is at the time not available
for .NET projects (neither WinForms nor WPF). That is also the case for the
Data Sources tool window, which relies on the Data Source Provider Service.
Object Data Sources are a great tool migrating business “Code-behind” logic
from Forms and UserControls into UI-stack-independent controller classes.
This way, it becomes easier for WinForms apps to be unit tested or reuse
business logic code in other contexts, and also have a clear migration path
to introduce modern technologies in WinForms LOB Apps.
The Advanced Databinding Dialog is now easier to handle and more accessible.
It now also allows the definition for entering property paths for complex
binding scenarios.
As always, please tell us which features you would like to see in the Designer
but also in the WinForms runtime around the databinding area.
Happy WinForms Coding!
The post Databinding with the OOP Windows Forms Designer appeared first on .NET Blog.
