I've refactored my WPF desktop app to be fully MVVM according Microsoft's definition of the design pattern. That includes binding the Views to their own Viewmodels, implementing data binding, commands and type converters for data binding. Speaking of type converters for data binding, it dawned on me that I was confusing that concept with XAML type converters. Nope, two completely separate mechanisms that provide for different functions. Anyway, the app is now nicely componentized and DRY but, because of the requirements of Microsoft version of MVVM and XAML, the codebase exploded in lines of source.
I was introduced to the Caliburn.Micro framework by one of Jack Xu's books. Caliburn.Micro implements a simplified MVVM binding process that reduces source code line count as compared to straight XAML binding. The problem is that I don't want to take the hit to convert to it at this point. Perhaps that's a bad idea.
I do very much appreciate using C# 7.2 as the language for the app. The language itself and its modern features, as well as the features of Visual Studio 2017, save quite a bit of typing. I am currently (12/2018) using .NET Framework 4.7.2. It's always hard to figure out where the language ends and the framework begins.
The async/await construct does indeed make multi-threaded code readable. The problem with async/await mechanism is that you really have to understand it well, it's not as simple as it looks (as it was intended to be). That is, going async in the async/await world does mean you're going multi-threaded. It can simply mean the UI thread moves on and the code that follows (under) the awaited call will resume after the awaited call returns, without switching threads - pure black magic. I do like the readability of the mechanism. Believe me, readability, as the app grows in size, is EVERYTHING.
Friday, October 12, 2018
Subscribe to:
Posts (Atom)