MVC und DOM

[molily]

Das sehe ich anders. Nehmen wir als Beispiel einen virtuellen Posteingang, dort habe ich eine Liste von eingegangen Nachrichten, jetzt möchte ich gerne eine Button haben, der alle ungelesenen Nachrichten markiert.
…
Die "Markierung" ist allerdings das "Verschwinden" aller gelesenen Nachrichten bzw. des Spams.

Ihr verwechselt da etwas: Änderungen am DOM und Änderungen auf Daten-Ebene.

Man neigt dazu, das DOM als Datenspeicher zu missbrauchen. Klassen regeln also nicht nur die Darstellung, sondern es sind quasi Felder gewisser Datensätze. Insbesondere jQuery regt einen mit jQuery.prototype.data() dazu an, Daten an DOM-Elementen zu speichern.

Das ist mittlerweile verpönt. Nicht-triviale JavaScript-Anwendungsfälle werden heutzutage mit einer MVC-artigen Architektur gelöst (oder MVVM, MVP…), bei der sämtliche Datenlogik in Model zu finden ist und es ferner Views zur Darstellung dieser Daten im DOM gibt. Mattis Beispiel mit Angular.js zeigt schön, wie man Model- und View-Logik hier trennen würde.

Die Information »Nachricht wurde gelesen«, »Nachricht wurde markiert« usw. wird dann nicht mehr direkt im DOM gespeichert. Das DOM repräsentiert die Daten nur, es wird nicht zum Speichern und Lesen dieses Nachrichtenstatus benutzt – das Model ist die einzige »Quelle der Wahrheit«.

Ein Posteingang ist dementsprechend eine Liste von Nachrichten-Models, und »wurde gelesen«, »wurde markiert« wird an den jeweiligen Models gespeichert. Die View erzeugt daraus eine Liste. Wie Klassen oder sonstige Angriffspunkte für Stylesheets gesetzt werden, ist der View überlassen. Wenn alle Nachrichten gelesen wurden, kann sie aus Performance-Gründen einfach zentral eine Klasse setzen, andernfalls jedem li-Element einzeln eine entsprechende Klasse geben.

Einen Überblick über MVC-Lösungen bietet TodoMVC. Interessierte können sich auch Chaplin ansehen (Link in der Signatur). ;)

Viele Grüße,
Mathias