So, I want to write a node system, specifically karnaugh and finite-state-machine graph, for fun, and I wonder about the approach. Should I first implement the node graph system separate from the GUI so that I could later implement it as a website? Because my first approach would be to use WPF, and I think the entire essence of this framework is to implement the logic in custom controls, but then that logic might be difficult to extract later?
Anyway, the way WPF seems to be built is that it encourages that I write the node and graphing logic as custom controls, and that making wrappers over separate logic would be doing a lot of things twice over, and I just can’t pick an approach. Any tips?
Mildly related: anyone have issues with XAML designer in .NET Core? It’s extremely laggy for me while working just fine in .NET Framework. Dragging a button across the design space and the button’s design anchor visuals lags behind. In VS Blend the Pen tool acts up in .NET Core projects and is unusuable.
If you are using proper MVVM techniques then your WPF solution should be easily portable to web if/when you want to do that. The bulk of your node network should exist in the Model layer. Your ViewModels will likely be quite simple things and your Views will be either custom controls (as you note) or DataTemplates. Your Model and data layers (I separate those personally) should be completely portable between platforms and if that starts to not be true then that should be a hint that you have architected something wrong.
Yeah, so that’s the idea that the system itself would be entirely separate from WPF.
This is where my confusion sets in as any example I’ve ever seen with WPF from Microsoft always binds dependencies very directly with the GUI framework. And I can understand that approach, as the entire idea I have in mind is inherently graphical in nature, it serves no purpose as a logic map in memory without a visual representation.
I know MVVM and all that, but it seems like a lot of plumbing to do something that has no need of models. By that I mean that a StateNode WPF-dependent customcontrol is where the real stuff lies, and it should be able to exist as representation of anything, really, no need to make a StateNodeModel class, it could just as well represent a Person and bind its TextBlock ControlTemplate “DisplayText” property to the object’s FirstName. The Person object should then still be represented as a state in the loop. Because the actual state-loop visualization is handled by a custom Canvas control, not some seperate linked list. That way a state could be any arbitrary object and the state’s value any arbitrary property, not a rigid node system.
Similar things that come to mind: plotting libraries. From what I’ve seen they don’t implement all the data point stuff separately, the chart visualization and sequences are dependent on WPF. You provide those visualization tools with your own arbitrary data, they don’t make them for you.