Modernizing .NETpad: Application State (Premium)

Developers often utilize design patterns that logically separate an app's presentation and business logic and use a third component to mediate between the two. The Windows Presentation Foundation (WPF) straddles the evolution of these design patterns. And its use of XAML files for declaring user interfaces tied to associated "code behind" C# files for event handlers was innovative and useful enough to have stood the test of time. So much so that Microsoft continued using this same model in subsequent app frameworks like Metro, UWP, MAUI, and the Windows App SDK.

WPF itself has also stood the test of time, as it remains a viable app framework today, almost 20 years after its introduction. And thanks to its popularity, Microsoft and various third parties have adapted WPF to adhere to popular design patterns over time. The most popular of these at first was something called the Model-View-Controller (MVC) pattern, in which the Model component handled internal logic, the View component handled the user interface, and the Controller acted as the mediator between the two. (NeXT used MVC and then brought this system to Mac OS X when that company acquired it.)

In more recent years, MVC has been supplanted by the Model-View-ViewModel (MVVM) design pattern, which was invented by two software architects at Microsoft in the early 2000s. And while I have no direct memory of this, it appears that it arrived roughly in-sync with WPF, based on the date of this archived MSDN blog post. At that time, the theory was that a professional application would be designed by a team of people that would include at least one designer who would work on the app UI (in XAML, in this case, but using a graphical tool that output the code) while at least one traditional developer would handle the necessary event handlers and other business logic, typically in C#. But there was another important aspect of MVVM that made it particularly well-suited to WPF: Data binding.

I've referenced data binding here and there throughout this series, mostly to voice my continued ignorance of how it works, despite it being so central to WPF. I'm still trying to understand WPF data binding, but when I first created .NETpad, I felt this app was so simple that learning MVVM and data binding was unnecessary, and that the overhead would outweigh the benefits. That said, I had to use a bit of data binding, even in that first WPF version of the app: The Fonts dialog--and now the font interface in app settings in the latest version--binds to the SystemFonts class in .NET to discover and display the available fonts, and to allow the user to change the font used by the app.

Tied to this, I've written about my refactoring of the code in .NETpad to be more elegant and efficient. As part of this effort, I separated the non-event handler code in the app into a separate C# file (backend.cs). I did this to better organize the code more logically, but if you were feeling generous, you might view...