MVC und Serialisieren

[Hardware]

Liebe Entwickler,

ich habe folgdende Situation:

ich habe eine Klasse TestModel.cs mit dem Inhalt
[XmlAttribute("name")]
public string Name;
[XmlElement("description")]
public string Description;
[XmlArray("testslist")]
[XmlArrayItem("test")]
public CeckControlModel[] TestList;

eine Klasse TestUI.cs

und eine Klasse CheckControlUI.cs
mit dem Model dafür

public class CeckControlModel
{
[XmlAttribute("name")]
public string Name;
[XmlElement("testdescription")]
public string Description;
[XmlAttribute("musclegroup")]
public string Musclegroup;
[XmlAttribute("exerciseID")]
public string ExerciseID;
[XmlAttribute("testID", DataType = "string")]
public string TestID;
}
}

So nun meine Frage wie und wo Serialisiere ich das Gedöns, weiß gar nicht wie ich das auspreche. Serialisiere ich die Daten sprich das Model ?

Wie bringe ich die UI und das Model zusammen und serialisiere dann die Daten ?

[Ralf Jansen]

Wie bringe ich die UI und das Model zusammen und serialisiere dann die Daten ?

Das sind irgendwie 2 Fragen. Wie man ein Model mit der UI zusammenbringt solltest du mit einer konkreteren Frage neu eröffnen. So in der Allgemeinheit ist das ein Frage nach einer Programmiererschulung die wir hier weder anbieten können noch wollen. Man kann dich im Moment nur die Doku verweisen die zu dem Stoff reichlich Informationen enthält.

Zum Serialisieren. Du hast ja anscheinend die XmlAttribute gefunden dann gehe ich mal davon aus das du auch den XmlSerialisierer gefunden hast. Wo ist das Problem denn einfach zu verwenden?

[Hardware]

Das sind irgendwie 2 Fragen.

Ok, ich versuche mal die Frage anders zu stellen.
Wie binge ich die UI und das Model so zusammen das ich später serialisieren kann. Ich kann das machen wenn die XmlAttribute direkt in die UI-Klasse schreibe, aber wie mache ich das wenn ich für die UI-Klasse ein Model mit den XmlAttributen erstellt habe. Das ist wahrscheinlich eher ein MVC - Problem aber mir erschließt sich das irgendwie nicht.

[Ralf Jansen]

Redest du hier von einer bestimmten Ausprägung von MVC? Wenn du das allgemeine Konzept meinst kann ich mit deiner Frage leider wenig anfangen. UI ist ein anderes Problem als Serialisierung die haben nix miteinander zu tun. Löse das Problem UI <-> Model und dann das andere Problem Model<->Persistenz. XmlAttribute gehört zum Model im Rahmen des 2.ten Problems und ist völlig im Rahmen von Problem 1 zu ignorieren.

[fanderlf]

Redest du hier von einer bestimmten Ausprägung von MVC? Wenn du das allgemeine Konzept meinst kann ich mit deiner Frage leider wenig anfangen. UI ist ein anderes Problem als Serialisierung die haben nix miteinander zu tun. Löse das Problem UI <-> Model und dann das andere Problem Model<->Persistenz. XmlAttribute gehört zum Model im Rahmen des 2.ten Problems und ist völlig im Rahmen von Problem 1 zu ignorieren.

Genau so sehe ich das auch. Versuche gar nicht erst überall dieselbe Entity zu verwenden. Damit kommst Du in die absolute Hölle, weil die Entity in viel zu vielen Kontexten verwendet wird. Du solltest es auch vermeiden (zumindest ist das mein Gefühl) direkt die Entities in die View zu pushen. Da gehört eigentlich immer so etwas wie ein ViewModel hin.

[Hardware]

Wie könnte den eine Lösung zu dem UI <-> Model Problem aussehen ?

mir ist schon klar dass das Lösen dieses Problem wahrscheinlich die Frage nach dem zweiten erübrigt. Aber ich möchte es tozdem zusammen behandeln. Eins nach dem anderen.

[Ralf Jansen]

Wie könnte den eine Lösung zu dem UI <-> Model Problem aussehen ?

Wie lautet denn das konkrete Problem? Wie gesagt auf dem allgemeinen Niveau kann ich dich nur an die Doku verweisen oder nur besonders intelligente Antworten geben wie "schreibe die Werte aus dem Model in die UI und am Ende der Bearbeitung zurück ins Model".

[Hardware]

"schreibe die Werte aus dem Model in die UI und am Ende der Bearbeitung zurück ins Model".

OK, wie kann man das machen bezogen auf mein Beispiel oben ?

[Ralf Jansen]

im simplen allgemeinen Fall

Control.Text = Model.Klasse.Property; // hin
Model.Klasse.Property = Control.Text; // zurück
// wiederhole für alle werte

im speziellen Fall keine Ahnung da du keinen nennst.

[fanderlf]

Ich denke in Zeiten von mächtigen UI Databinding Frameworks ist das klassische MVC Pattern etwas angestaubt. In meiner Definition des klassischen MVC Patterns gibt es keinerlei Databinding und jegliche Kommunikation zwischen UI und Model erfolgt per Hand. Deswegen würde ich mich darauf nicht mehr so arg versteifen. Im Zusammenhang mit Databinding funktioniert so etwas wie MVVM wesentlich besser.

Bei MVVM erstellt eine Klasse (das ViewModel) welche im Endeffekt alle Eingabemöglichkeiten der UI in einer Klasse abbildet (Textbox -> String, OnClick -> Funktion,...). Der große Unterschied zu MVC ist allerdings dass das ViewModel per Databinding vom View an die UI gebunden wird. Danach kümmert sich das ViewModel um alle Aufgaben die von der View erledigt werden können.

Kleines Beispiel in der man eine Namensliste pflegen könnte und jeden Namen der insgesamt in der Datenbank steht jeweils einmal sieht. Eigentlich relativ sinnfrei, aber ich denke man sieht wie MVVM funktioniert

public class Name
{
  public String Vorname { get; set; }
  public String Nachname { get; set; }
}

public interface INameRepository
{
  IEnumerable<Name> GetAll();
  Save(Name newName);
}

public class NameViewModel
{
  private readonly INameRepository _nameRepository;

  public NameViewModel(INameRepository nameRepository)
  {
    _nameRepository = nameRepository;
  }

  public IEnumerable<String> Vornamen { get { return _nameRepository.GetAll().Select(x => x.Vorname).Distinct(); } }
  public IEnumerable<String> Nachnamen { get { return _nameRepository.GetAll().Select(x => x.Nachname).Distinct(); } }

  public String NeuerVorname { get; set; }
  public String NeuerNachname { get; set; }

  public void Speichern()
  {
    _nameRepository.Save(new Name() { Vorname = NeuerVorname, Nachname = NeuerNachname });
    // Hier müsste man der UI sagen dass sich die Vor- und Nachnamen geändert haben - das ist allerdings UI spezifisch
  }
}

Das ganze Teil könnte man jetzt z.B. in WPF oder Windows Forms sehr leicht an die UI binden und hätte damit die komplette Logik der UI in einer abstrakten Klasse erschlagen.

[Hardware]

Ich denke in Zeiten von mächtigen UI Databinding Frameworks ist das klassische MVC Pattern etwas angestaubt.
Das ganze Teil könnte man jetzt z.B. in WPF oder Windows Forms sehr leicht an die UI binden und hätte damit die komplette Logik der UI in einer abstrakten Klasse erschlagen.

Das ist alles wunderbar (hast du hier LINQ benutzt ? ) und ich würde gerne später darauf zurückkommen, danke für ein schönes beispiel. Aber ich brauche ein Beispiel in MVC weil ich es verwenden muss.

[Hardware]

Control.Text = Model.Klasse.Property; // hin
Model.Klasse.Property = Control.Text; // zurück
// wiederhole für alle werte

Control.Text - verstehe ich -
Model.Klasse.Property - kannst du das etwas näher erklären ?
Ist das ein statisches Model ? oder ist es kein Aufruf einer Property ?
Ich habe doch einen konkreten Fall genannt.

weiter oben habe ich doch zwei Models:
Sie stellen jeweils ein Usercontrol und eine Reihe die diese Usercontrols zusammenfassen soll. Etwa eine Serie aus BenutzerControlls.

UI = View = Serie mit Name der Serie + Beschreibung + n-mal Zusammengesetzte Controlls
TestModel = Model = UserControl (mit Name Beschreibung Musklegruppe usw. siehe oben )
GedönsController = Controller (noch kein Plan)

[fanderlf]

MVC macht das ganze im Prinzip ohne Databinding. Also praktisch:

Der Einfachheit wegen nehme ich ein paar Klasse von vorhin wieder her

public interface INameView
{
  IEnumerable<String> Vornamen { set; }
  IEnumerable<String> Nachnamen { set; }
  String NeuerVorname { get; set; }
  String NeuerNachname { get; set; }
  event EventHandler Speichern;
}

public class Controller
{
  private readonly INameView _view;
  private readonly INameRepository _repository;

  public Controller(INameView view, INameRepository repository)
  {
    _view = view;
    _view.Speichern += SpeichereName;
    ZeigeNamen();
  }

  private void ZeigeNamen()
  {
    var alleNamen = _repository.GetAll();
    _view.Vornamen = alleNamen.Select(x => x.Vorname).Distinct();
    _view.Nachnamen = alleName.Select(x => x.Nachname).Distinct();
  }

  private void SpeichereName(object sender, EventArgs e)
  {
    //Daten aus UI holen
    var neuerName = new Name() { Vorname = _view.NeuerVorname, Nachname = _view.NeuerNachname };

    //Objekt speichern
    _repository.Save(neuerName);

    //Alle Objekte neu holen und anzeigen
    ZeigeNamen();

    //Namen Eingabe zurücksetzen
    _view.NeuerVorname = "";
    _view.NeuerNachname = "";
  }
}

public class WindowsFormsNameView: IView
{
  private Controller _controller;

  public WindowFormsNameView()
  {
    _controller = new Controller(this, new NameRepository()); // NameRepository gibt es nicht wäre aber im Endeffekt eine CRUD Klasse z.B. auf eine Datenbank
  }
  
  public IEnumerable<String> Vornamen 
  { 
    set
    {
      textBoxVornamen.Text = String.Join("\r\n",value);
    }
  }

  public IEnumerable<String> Nachnamen 
  { set
    {
      textBoxNachnamen.Text = String.Join("\r\n",value);
    }
  }

  
  public String NeuerVorname 
  { 
    get
    {
      return textBoxNeuerVorname.Text;
    } 
    set
    {
      textBoxNeuerVorname.Text = value;
    }
  }

  public String NeuerNachname 
  { 
    get
    {
      return textBoxNeuerNachname.Text;
    } 
    set
    {
      textBoxNeuerNachname.Text = value;
    }
  }

  private void buttonSpeichern_Click(object sender, EventArgs e)
  {
    Speichern(this, new EventArgs());  
  }

  public event EventHandler Speichern;
}

Das ist jetzt auch nur runter getippt. Das ist jetzt aber auch nur meine Auslegung von MVC. Wenn jemand anderer Meinung ist darf er mich gerne belehren. Was ich an diesem Beispiel von MVC sehr schön finde ist, dass man genau sieht was man mit der UI alles anstellen kann. Man kann z.B. die Namenslisten nur setzen. Das heisst es ist eine reine Anzeigeproperty. Ausserdem sollte man versuchen möglichst viel Logik in den Controller zu verschieben da dieser ein POCO sein sollte und deswegen auch leichter zu testen ist als der View.

Heutzutage würde ich dieses Muster nur dann empfehlen wenn es für das UI kein entsprechendes Databinding Framework gibt oder die Logik extrem kompliziert ist und man sehr feingranulare Kontrolle darüber haben will was passiert. An manchen Stellen kann man so auch unperformantem Databinding aus dem Weg gehen.

[Ralf Jansen]

Control.Text - verstehe ich -
Model.Klasse.Property - kannst du das etwas näher erklären ?

Da gibt es nichts näher zu erklären. Model ist immer irgendein Konstrukt. Darum steht hier nur irgendein Platzhalter der beliebig zu füllen ist. Wie das Model konkret aufgebaut ist deine Entscheidung da macht MVC keinerlei Vorgaben.
Eigentlich habe ich hier auch nur die Ironie Tags vergessen. Wie man Daten aus einer wie auch immer gearteten Variablen die man in Summe dann Model nennt in ein UI Control bekommt und wieder zurück sollte dir eigentlich schon klar sein bevor du dich mit MCV beschäftigtst. Sonst kommt das Thema zu früh für dich.

UI = View = Serie mit Name der Serie + Beschreibung + n-mal Zusammengesetzte Controlls
TestModel = Model = UserControl (mit Name Beschreibung Musklegruppe usw. siehe oben )
GedönsController = Controller (noch kein Plan)

Ich weiß nicht genau worauf du hinaus willst aber UserControl hat nichts mit dem Model zu tun. Wenn du mit UserControl wirklich das Control meinst.
Die sollten voneinander möglichst nix Wissen. Wie du in fanderlf's Beispiel auch siehst steckt da ein Controller dazwischen der vermittelt (und technisch die beiden anderen kennt bzw. zumindest deren Interfaces). Also halte die nicht nur technisch auseinander sondern auch gedanklich. Das "n-mal Zusammengesetzte Controlls" hört sich so an als wären das dann auch jeweils ein eigener MVC Konstruct. Denn VC Teil von MVC kann man ja mehrmals instanziieren und innerhalb eines übergeordneten VC Teils verwenden.