Going XAML/WPF Requires new threading model, and Legacy WinForms Charting

The conversion from WinForms/VB.NET to WPF/C#.NET is tougher than anticipated. WPF is designed, by way of XAML, to have a data pull, autonomous, UI system. Base on a design pattern called Model-View-ViewModel (MVVM). The pattern should have been called View->Viewmodel->Model (V>VM>M) since the View is only supposed to know about (references) the Viewmodel and the Viewmodel is only supposed know about (references) the Model. I also found out that WinForms Chart class was not ported to or supported by WPF. Therefore, I'm mostly tossing the View/ViewModel binding concerns and concentrating on core functionality of the app.  That is, charting real-time data and while keeping the UI interactive. So that means wrapping the WinForms Charting namespace to work in WPF and converting WinForms BackgroundWorker threads to work in a WPF environment. The application is forced by XAML to be partitioned at a high level into Windows, User Controls and Pages, each locked to their own partial class and inheritance chain. This architecture requires a lot of inter-class access facilitation. Not to mention the added complexity of trying to adhere to the MVVM pattern of the View only knowing of the ViewModel and the ViewModel only knowing of the Model. It's a challenge.

Of course, working with C#.NET is easier than VB.NET.

My brain has been XAML'ed...

I'm starting the next major step which is to convert the VB.NET WinForms application with the 64bit Win32 DLL dependency to a 100%, modern, C#.NET, WPF application. I'm doing this to get the higher performance and capability graphics APIs. This will require me switch out the WinForms controls and layout for XAML controls and layout - two completely different implementations and methodologies. XAML is big and complicated, born mostly from having a several ways to accomplish the same result (very typical of Microsoft products).

The first hurtle is get enough competence in XAML to just understand where to start. Then after that, I have to decide whether to implement using XAML or in code behind. Blah. I know where this is going - start with naive top-down, functional design approach and refactor, refactor and refactor.