Note: I am a newbie in all fields involved (WPF, MVVM pattern, GraphSharp/QuickSharp libraries).
I am trying to display a simple directed graph using the GraphSharp library. I went through this demo, and wrote some very similar code (creating custom Vertex, Edge, Graph and GraphLayout types etc.).
Next, I added a Status property to my custom Vertex type and implemented a data template and a style resource in my XAML code (somewhat similar to the demo linked above), which applied various styles to the vertex controls based on their Status property. For this, I had to implement the INotifyPropertyChanged interface in my custom Vertex type. I also have some other codes that change the Status property of vertexes at runtime, triggering the style changes. All this works, so far, so good.
Next I read a couple of articles about how WPF code should be organized into model, view model and view layers: the view (preferably only XAML code) should only talk to the view model classes (via Bindings), the latter implementing INotifyPropertyChanged and that the view model should only talk to the "business logic" implemented in the model classes. This all sounds nice, but now I'm pretty confused about what belongs where:
The XAML code is the view, so far it's simple.
The custom GraphLayout type seems to belong to the view model layer.
I'd guess that the custom vertex, edge and graph types belong to the model layer. Except that now the custom vertex type implements INotifyPropertyChanged, which seems to be a trait of view model classes.
The code changing the custom vertex's Status property makes use of the QuickGraph base classes funcionality (BidirectionalGraph.OutEdges() for example), so it should belong to the model layer. But: if the custom graph belongs to the view model, then why does a model class call a view model class to determine anything that's related to business logic.
So the main question is: what is the preferred class structure for a program like this? Which classes belong to the model, view model and view layers?