{"id":44066,"date":"2023-01-25T10:15:00","date_gmt":"2023-01-25T18:15:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=44066"},"modified":"2023-01-31T11:26:08","modified_gmt":"2023-01-31T19:26:08","slug":"winforms-cross-platform-dotnet-maui-command-binding","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/winforms-cross-platform-dotnet-maui-command-binding\/","title":{"rendered":"Using Command Binding in Windows Forms apps to go Cross-Platform"},"content":{"rendered":"

Large line-of-business WinForms applications can often benefit from the use of\nthe Model-View-ViewModel (MVVM) pattern to simplify maintenance, reuse, and unit\ntesting. In this post, I’ll explain the important concepts and architectural\npatterns of MVVM including data binding and command binding. Then we will take a look at how you can leverage modern libraries, .NET 7 features,\nand Visual Studio tooling to efficiently modernize your WinForms applications. By the end, you will see how this approach sets your application up to go cross-platform with popular frameworks like .NET MAUI which can leverage the MVVM code across iOS, Android, Mac, and Windows.<\/p>\n

Say Goodbye to Code-behind: WinForms meets MVVM & .NET MAUI<\/h2>\n

One of the features that has led WinForms to its overwhelming popularity as a\nRAD (rapid application development) tool is often, for large line-of-business\napps, also its biggest architectural challenge: placing application logic as\ncode behind UI-Element’s event handlers. As an example: The developer wants to\ndisplay a database view after a mouse click on a pulldown menu entry. The\npulldown menu is located in the main form of the application. This form is a\nclass derived from System.Windows.Forms<\/code>, so it has dependencies to the .NET\nWinForms runtime. This means every line of code put here can only be reused in\na context of a<\/em>, probably even only if the context of exactly this<\/em> WinForms\napp. Typically for WinForms, user interaction with any UI elements triggers\nevents. These events are then handled in corresponding event handler routines,\nand this approach is often called code-behind<\/em>. So, the code behind<\/em> the menu\nentry is triggered. In many cases, the form is now executing the logic for a\ndomain-specific task that basically has nothing to do with the UI. For large\nline-of-business apps, this can quickly become an architectural nightmare.<\/p>\n

In the case of this example, the code which is executed as a result of a user\nclicking a menu item contains many steps. The form connects to a database, sends\na query to that database, then feeds the data, perhaps prepares it by performing\nadditional calculations or pulling in additional data from other sources, and\nfinally passes the resulting data set to another WinForms form which it then\npresents in a DataGridView<\/code>. Code-behind application architectures in this way\ntend to easily mix domain-specific with UI-technical tasks. The resulting\ncodebase is not only difficult to maintain, it is also hard to reuse in other\nscenarios, let alone easily support unit testing of the business logic.<\/p>\n

Enter UI-Controller architecture<\/h2>\n

With the introduction of Windows Presentation Foundation (WPF) in 2008, a new\ndesign pattern emerged that set out to clean up the code-behind spaghetti\narchitecture of previous UI stacks and introduced a clear separation of code\nbased on the layer in the application: UI-relevant code remained alone in a view\nlayer, domain-specific code migrated to a ViewModel layer, and additional data\ntransport classes, which were used to transport data from a database or an alike\ndata source and were processed in the view model, were simply called Model<\/em>\nclasses.<\/p>\n

The name of the pattern became Model-View-ViewModel<\/em>, or MVVM<\/em> for short. The\nprocessing of data and the execution of the domain-specific code are reserved\nfor the ViewModel. As an example, the business logic for an accounting\napplication only runs in the context of one (or more) ViewModel assemblies.\nProjects that build these assemblies have no references to concrete UI stacks\nlike WinForms, WPF or .NET MAUI. Rather, they provide an invisible or virtual UI\nonly through properties, which are then linked to the UI at runtime via data\nbinding.<\/p>\n

This technique is not entirely new for WinForms apps. Abstraction via\ndata binding was already common practice in the VB6 days and became even more\nflexible with WinForms and the introduction of Typed DataSets. The abstraction\nof data and UI worked according to the same principle then as it does today: The\nvarious properties of a data source (in MVVM the ViewModel, in typical WinForms\nor VB6 architectures often a filtered and specially prepared view of the\ndatabase directly) are bound to specific control elements of the UI. The\nFirstname<\/code> property of a data source class is bound to the Text<\/code> property of\nthe FirstnameTextBox<\/code> control. The JoinDate<\/code> property of the same data source\nclass is bound to the Value<\/code> property of the JoinDateTimePicker<\/code> control, and\nso on. Even the notifications of the data classes to the UI that data has\nchanged worked in the first WinForms versions in the same way as is still the\ncase today in WPF, WinUI or .NET MAUI: data classes implement an interface\ncalled INotifyPropertyChanged<\/code>. This mandates an event called PropertyChanged<\/code>\nfor the data source classes. It is then the task of the data classes to\ndetermine in the respective setters of the property implementations whether the\nproperty value had really changed and, if this is the case, to trigger the\ncorresponding event, specifying the property name. A typical implementation of a\nproperty in a class looks something like this:<\/p>\n

    public class NotifyPropertyChangeDemo : INotifyPropertyChanged\n    {\n        \/\/ The event that is fired when a property changes.\n        public event PropertyChangedEventHandler? PropertyChanged;\n\n        \/\/ Backing field for the property.\n        private string? _lastName;\n        private string? _firstName;\n\n        \/\/ The property that is being monitored.\n        public string? LastName\n        {\n            get => _lastName;\n\n            set\n            {\n                if (_lastName == value)\n                {\n                    return;\n                }\n\n                _lastName = value;\n\n                \/\/ Notify the UI that the property has changed.\n                \/\/ Using CallerMemberName at the call site will automatically fill in\n                \/\/ the name of the property that changed.\n                OnPropertyChanged();\n            }\n        }\n\n        public string? FirstName\n        {\n            get => _firstName;\n\n            set\n            {\n                if (_firstName == value)\n                {\n                    return;\n                }\n\n                _firstName = value;\n                OnPropertyChanged();\n            }\n        }\n\n        private void OnPropertyChanged([CallerMemberName] string propertyName = \"\") \n            => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));\n    }<\/code><\/pre>\n
In summary, the general idea is to remote-control the actual UI through data\nbinding. However, in contrast to the original thought coming from VB6 and the\nclassical WinForms data binding, using a UI-Controller pattern like MVVM is more\nthan a convenience to populate a complex form with data: While VB6 and classic\nWinForms applications typically only used populated data classes like Typed\nDataSets or Entity Framework model class instances, the ViewModel holds the data\nand<\/em> encapsulates the business logic to prepare that data logically in such a\nway that practically the only task of the UI layer is to present the data in a\nuser-friendly way.<\/p>\n
UI-Controller Architecture in WinForms: To what end?<\/h3>\n
If you wanted to architect and develop a new application from scratch, you would\nmost likely consider using a modern UI stack for your new development endeavors,\nand in many cases, that makes sense. If you were to start developing a new\nWindows app from scratch, a more modern stack like\nWinUI<\/a>\nmight be a meaningful alternative. Alternatively, a web-based front end and\nadapting technologies like\nBlazor<\/a> or\nAngular\/TypeScript<\/a>\nalso have merit. But it’s often not that easy in real life. Here is a list of\npoints to consider, why adapting a UI-Controller architecture for new or\nexisting WinForms apps makes sense:<\/p>\n