keine Ahnung.
Bei mir unterscheidet das Viewmodel, ob Laufzeit ist oder Designzeit - zur Designzeit werden paar Dummi-Daten generiert, zur Laufzeit holts auch mal richtig Daten. Der DataContext wird im Xaml festgelegt - nicht im Codebehind, und dann funzt auch das Binding-Picking im Xaml-Editor.

Die übliche Wpf-Gemeinde neigt imo immer zu einem Mords-Zinnober, mit LocatorService, IOC-Container, IOC-Service-ServiceManager, ServiceManagerLocator, ModelBehaviorBehaviorService, BehaviorServiceContainerGenerator - also ich finds immer unglaublich, was die sich alles einfallen lassen, meist um die Entkopplung zu entkoppeln, und die Entkopplungs-Entkopplung dann nochmal zu entkoppeln.

Und am Ende haben sie 20 Klassen, 1000 Zeilen Code, und können sie eine Liste von Personen anzeigen (wow!). Und leider funktioniert nichtmal das BindingPicking mehr

Mein Vorschlag: Achte drauf, dass BindingPicking funktioniert, und dass du keinen CodeBehind in Anspruch nimmst. Hast du dann ein konkretes Problem, frag nochmal.
nicht von Architektur-Astronauten einschüchtern lassen

Mit einfacher Architektur anfangen, und Komplexität zufügen, wenns kompliziert wird - nicht vorher. Ich trenne meist sogar nichtmal Model von Viewmodel. (Aber wenn nötig, dann eben doch.)

Also bei mir verwaltet auch das ViewModel dies, hab da einfach die INotifyPropertyChanged-Basisklasse von thefiloe genommen und eben eine ViewModelBase samt ViewModel für die einzelnen Windows. Dann die Bindings machen und gut ists. Kann also beides dann abgeholt werden.

Bedenke, dass ein extra DataService durch aus in vielen Fällen durchaus seine Berechtigung hat. Und über die Einstellung von EDR, dass man auf keinen Fall auch nur irgendwas zuviel programmieren soll um eine gewisse Erweiterbarkeit zu behalten, ist sehr oft auch einfach nur fehl am Platz. Das heißt nicht, dass man kp. was für nen Zirkus veranstalten muss aber man durchaus auch etwas vorausdenken.

So ein DataService kann gerade auch bei verschiedenen Datenquellen hilfreich. Zu einem Muss wird das spätestens dann, wenn du Drittsysteme integrieren sollst. Ein übliches Beispiel wäre z.B. die Anbindung an ein SAP System. Das Problem ist hier, dass du sehr oft kein Testsystem zur Verfügung hast und keine Firma die halbwegs bei Trost ist, lässt dich an deren SAP-System ran. Somit kannst du z.B. einen MockDataService implementieren. Dieser beliefert dich mit Daten und kann unter gewissen Umständen diese auch wieder speichern. So kannst du die komplette Applikation ohne ein SAP-System programmieren. Am Ende kannst du dann immernoch den SAPDataService implementieren. Es gibt unzählige solche Beispiele.

hey - ich glaub, ich hab auch mal einen DataService geschrieben!

DBExtensions

Und das ist tatsächlich sowas, wo du der Anwendung unterm Hintern die Persistenz-Schicht austauschen kannst, ohne dass sie's merkt.
Also die einfache Persistenz-Schicht läuft übern XmlDatasetAdapter, und fett die DB-Zugriffe laufen übern DatasetAdapter, und beide erben von DatasetAdapterBase - das ist dann wohl der DataService, oder?

Und das ist getreu meinen Prinzipien entstanden: Komplexität habich hinzugefügt, als es kompliziert wurde. Also den XmlDatasetAdapter gabs bereits, und erst als der DbDatasetAdapter prototypisch funzte, habich mir den XmlDatasetAdapter vorgeknöpft, und eine Basisklasse extrahiert, die all das vereinigt, was im DatasetAdapter gleichartig funktioniert wie im XmlDatasetAdapter. Das ist in dem Fall wirklich sehr sehr schön aufgegangen, und jede andere Vorgehensweise wäre umständlicher gewesen, und hätte v.a. höchstwahrscheinlich ein schlechteres Ergebnis erbracht.

Und auch die Verwendung von (Xml-)DatasetAdapter funktioniert nun nach dem "Lazy-Complexity-Prinzip": (Erst) Wenn du mit dem (niedrig komplexen) Abspeichern als Xml nicht mehr hinkommst - mach stattdessen 'ne (komplexere) DB-Persistenz dahinter.