In den ersten beiden Lektionen dieses Kurses ist die Kladde zu einer App geworden: Es gibt Seiten für Kontakte und für die Termine des Tages, verbunden durch Shell, mit festen Beispieldaten im Code. Das trägt für einen Prototyp. Sobald Daten aus einer Web-API kommen, ein Formular Regeln hat und jemand eine Änderung prüfen soll, wird der Code hinter den Seiten zum Problem: Er lässt sich nur mit einem laufenden Emulator ausprobieren. Diese Lektion trennt die Logik von der Oberfläche, bis sie sich mit dotnet test prüfen lässt.

Der Schnitt dieser Lektion:

Teil Was entsteht
Muster Model, View und ViewModel, und was die Bindung dazwischen tut
Toolkit ObservableObject, [ObservableProperty], [RelayCommand]
Verdrahtung Dependency Injection in MauiProgram, Navigation hinter einer Schnittstelle
Prüfung ein Projekt Kladde.App.Logic ohne MAUI und ein Testprojekt dazu

Wo die Kladde steht

Der Kurs setzt voraus, was die Lektion W2.1.2 gebaut hat. Zur Sicherheit das Bild, von dem diese Lektion ausgeht:

  • Es gibt das Projekt src/Kladde.App (die MAUI-App, Namensraum Kladde.App), das auf dem Android-Emulator und unter Windows startet. Es steht noch nicht in Kladde.slnx; diese Lektion legt fest, wie es dazu kommt.
  • Im Ordner Models liegen die Records ContactResponse (Id, Name, Email, Company, Tags) und AppointmentResponse (Title, Start, End, ContactIds) und die statische Klasse SampleData mit den festen Kontakten und den Terminen von heute.
  • Im Ordner Pages liegen ContactsPage, ContactDetailPage und AppointmentsPage. Die Shell kennt die Route contactdetails für die Detailseite, die ihren Kontakt über IQueryAttributable aus einem Wörterbuch bekommt.
  • Die Seiten haben Code-Behind, der die Listen aus SampleData füllt.

Ihre Seiten und Klassen heißen vielleicht anders. Behalten Sie Ihre Namen und übertragen Sie die Schritte. Neu in dieser Lektion ist die Seite NewAppointmentPage im Namensraum Kladde.App.Pages.