Warum wird bei Tutorial über MVVM eine leere Klasse "StudentModel" erstellt?

Guten Abend. 😃
ich hätte eine kleine Verständnis frage über die Erstellung des Models, wenn man das Pattern MVVM in sein Projekt einbinden will.

Ich habe mir im groben die Grundlagen des C# angeeignet und auch schon die ein oder andere kleine Anwendung entwickelt. Um "anständig" und "sauber" zu entwickeln und meine Projekte Unit-Test (Derzeit weiß ich noch nicht viel darüber, nur, dass Sie sehr nützlich sein können, wenn man sein Projekt, wer hätte es geahnt, testen möchte 😃) freundlicher zu gestalten habe ich mir vorgenommen mir das MVVM-Pattern anzueignen woraufhin ich auf das Tutorial hier gestoßen bin.
MVVM â First Application
Dort wird relativ am Anfang im Model die Klasse StudentModel erstellt, indem allerdings eine weitere klasse ist und zwar Student

    public class StudentModel { }

    public class Student : INotifyPropertyChanged
    {
       
         //….
         //….

        #region INotifyPropertychanged event
        public event PropertyChangedEventHandler PropertyChanged;
        private void RaisePropertyChanged(string property)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(property));
            }
        }
        #endregion
    }

Was ich daran nicht ganz nachvollziehen kann ist, wieso eine komplett leere Klasse erstellt wird welches er StudentModel nennt? Ist dies tatsaechlich zwingend erforderlich oder birgt es irgendwelche Vorteile ? Leider geht er auch nicht darauf ein warum er dies tut.

Sollte ich im falschen Forum-Bereich sein bitte ich doch drum mich an die richtige Stelle zu verschieben.

Mit freundlichen Grüßen. 😃

Ich kenne das Tutorial nicht, aber ich denke, dort geht es um das Datenbank-Model.

Ein (Student)Model-Objekt enthält die direkten Daten von der Datenbank, oder (wenn man eine Business-Schicht dazwischen hat) es ist ein weiteres BusinessObjekt darüber, was selber das Datenbank-Model enthält und zusätzlich diverse Business-Funktionen anbietet.

Das ViewModel liegt wiederum darüber, es trägt das Model und bildet die Schnittstelle zwischen diesem Model und der View. Es bereitet die Daten für die View auf und umgekehrt von der View für das Model. Es kann auch die Business-Funktionen für die View passend anbieten, z.B. in Form von Commands, die dann an Buttons gebunden werden.

Kurz gesagt heißt das:
Das ViewModel bereitet die Daten für die Kommunikation zwischen Model und View und umgekehrt vor.
Das Model enthält allgemeinere Daten, die in keinerlei Zusammenhang mit der View stehen.

Warum das Model hier leer ist?
Keine Ahnung, vielleicht vertraut der Autor darauf, dass man sich die Student-Daten dazu denkt?
Ich finde das etwas kontraproduktiv, besonders da es für einen Anfänger sowieso schon schwer ist, den Sinn der Aufteilung von Model und ViewModel in einem kleinen Projekt zu erkennen. Wenn man die Inhalte weglässt, wirkt das ja erst recht sinnlos.

Hey Palladin007

Vorab schon einmal vielen dank für deine schnelle Antwort. 😃
Also wie ich das aus dem Tutorial entnehmen kann ist keine Datenbank eingebunden. Die Codestelle hatte ich etwas abgekürzt gehabt.
Wenn ich dich richtig verstanden hab bietet das Model quasi die Bausteine für die Datenbank (oder eine andere Datenquelle)
StudenModel

using System.ComponentModel;

namespace MVVMDemo.Model {
 
   public class StudentModel {}
	
   public class Student : INotifyPropertyChanged {
      private string firstName; 
      private string lastName;
		
      public string FirstName { 
         get { 
            return firstName; 
         }
			
         set { 
            if (firstName != value) { 
               firstName = value; 
               RaisePropertyChanged("FirstName"); 
               RaisePropertyChanged("FullName"); 
            } 
         } 
      }
		
      public string LastName { 
         get {return lastName; } 
			
         set {
            if (lastName != value) { 
               lastName = value;
               RaisePropertyChanged("LastName");
               RaisePropertyChanged("FullName"); 
            } 
         } 
      }
		
      public string FullName { 
         get { 
            return firstName + " " + lastName; 
         } 
      }
		
      public event PropertyChangedEventHandler PropertyChanged;
		
      private void RaisePropertyChanged(string property) {
         if (PropertyChanged != null) {
            PropertyChanged(this, new PropertyChangedEventArgs(property));
         } 
      } 
   } 
}

ViewModel

using MVVMDemo.Model; 
using System.Collections.ObjectModel;

namespace MVVMDemo.ViewModel { 

   public class StudentViewModel { 
	
      public ObservableCollection<Student> Students { 
         get; 
         set; 
      }
		
      public void LoadStudents() { 
         ObservableCollection<Student> students = new ObservableCollection<Student>();
				
         students.Add(new Student { FirstName = "Mark", LastName = "Allain" }); 
         students.Add(new Student { FirstName = "Allen", LastName = "Brown" }); 
         students.Add(new Student { FirstName = "Linda", LastName = "Hamerski" }); 
			
         Students = students; 
      } 
   } 
}

Aus dem hervorgehenden Code kann ich nachvollziehen, ein wenig wenigstens, wie der ablauf zwischen Model-ViewModel sein soll. Ich kann halt nur absolut nicht nachvollziehen wieso er die Klasse StudentModel nennt, die klasse Leer lässt aber im selben Namespace die klasse Student erstellt und die Daten dort hat. Das irritiert mich etwas

Also für mich sieht die "Student"-Klasse wie ein "StudentViewModel" aus - würde ich persönlich auch immer so nennen, aber da gibt's bestimmt auch andere Meinungen.
Die Model-Klassen würde ich persönlich nicht Model nennen, aber auch das ist Geschmack. Es gibt z.B. auch Leute, die nennen die POCO-Klassen, die sie mit einem ORM nutzen, irgendetwas mit "T_" und verdeutlichen so ihre Funktion.

Das Model kann im Grunde alles sein, hauptsache es hat nichts mit der View zu tun. Ein gut umgesetztes Model könnte z.B. genauso in eine ASP.NET-Anwendung mit dem MVC-Pattern verwendet werden, oder es stellt die Grundlage für eine Konsolen-Schnittstelle bereit, oder es wird unabhängig von WPF oder ASP.NET in UnitTests getestet.
Es ist unabhängig von der großen View-Schicht, die ihrerseits ViewModel und View enthält. Bei einfachen Anwendungen würde das ViewModel viele Daten nur durch schleifen, man könnte aber z.B. auch eine Undei/Redo-Funktion umsetzen und/oder das ViewModel schreibt die Daten erst zurück ins Model, wenn man aktiv speichert.

Sehe ich das richtig, dass "StudenModel" gar nicht genutzt wird? So betrachtet sehe ich darin auch keinen Sinn 😄
So fände ich es persönlich verständlicher:

namespace Anwendung.Data
{
    public class StudentModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        // Weitere Properties ...
    }
}

namespace Anwendung.View
{
    public class StudentViewModel
    {
        private string _firstName;
        private string _lastName;

        public string FirstName
        {
            get => _firstName;
            set
            {
                if (_firstName != value)
                {
                    _firstName = value;
                    RaisePropertyChanged(nameof(FirstName));
                    RaisePropertyChanged(nameof(FullName));
                }
            }
        }
        public string LastName
        {
            get => _lastName;
            set
            {
                if (_lastName != value)
                {
                    _lastName = value;
                    RaisePropertyChanged(nameof(LastName));
                    RaisePropertyChanged(nameof(FullName));
                }
            }
        }
        public string FullName
        {
            get => FirstName + " " + LastName;
        }
        // Weitere Properties ...

        public void WriteData(StudentModel model)
        {
            model.FirstName = FirstName;
            model.LastName = LastName;
            // Weitere Properties ...
        }
        public void ReadData(StudentModel model)
        {
            FirstName = model.FirstName;
            LastName = model.LastName;
            // Weitere Properties ...
        }
    } 
}

das genannte mvvm tutorial ist eher ein schlechtes beispiel.

hier im forum gibt es eins das verständlicher gestaltet ist.

[Artikel] MVVM und DataBinding

MVVM besteht aus 3 teilen die man auch deutlich machen sollte in seiner eigenen nameskonvention.

letztendlich ist es aber wichtig das man weiss

view = ist das was der benutzer sieht. der view selber kennt das model nicht

viewmodel = stellt die aufbereiteten daten und logik für das view zur verfügung. das viewmodel kennt den view nicht

model = hält die daten bereit die das viewmodel verarbeitet. das model kennt weder den view noch das viewmodel.

gruß