View first basiert nicht auf einem Modell und einem Controller, sondern hauptsächlich auf der Ansicht. Viele Problemdomänen sind in Controllern und Modellen nicht sauber zusammengefasst. Denken Sie an eine E-Commerce-Website, der Warenkorb existiert auf allen Seiten, aber sollte jeder Controller das kontrollieren? Persönlich in MVC wird zu viel Zeit damit verbracht, darüber nachzudenken, wie man das Problem logisch in MVC einpasst, anstatt nur zu codieren. Die Ansicht entfernt zuerst diesen Controller / View / Model und hat stattdessen nur eine Ansicht, die in Lift "Snippets" aufrufen kann. Es ist fast eine Obermenge von MVC, da Sie, wenn Sie wollten, nur ein einziges Snippet pro Seite haben könnten, aber mit Lift können Sie viel mehr tun. Snippets können Cross-Cut-Probleme oder sehr page-spezifische Logik sein.
Von der Website des Aufzugs ..
Lift ist anders [von MVC]. Bei HTML-Anfragen lädt Lift die Ansicht zuerst und erstellt Ihre Seite aus der Ansicht. Lift unterstützt auch REST-Style-Anforderungen für Nicht-HTML-Daten. (Siehe 11 auf Seite 1 ↑) "Warum?" Weil komplexe HTML-Seiten selten eine dominante Logik enthalten ... einen einzelnen Controller ... aber viele verschiedene Komponenten enthalten. Einige dieser Komponenten interagieren und andere nicht. In Lift definieren Sie die Sammlung von Komponenten, die in der resultierenden HTML-Seite in der Ansicht gerendert werden sollen.
Wenn Sie lift verwenden, haben Sie im Grunde eine Ansicht (Seite), und Sie können damit jedes Snippet (App) einbinden, das Sie ohne die Possen haben, die Sie normalerweise in einem MVC-Framework / Umgebung machen müssten / p>
Grundsätzlich müssen Sie nicht auswählen, was das Wichtigste auf der Seite ist, was Sie einer Seite hinzufügen und dann hinzufügen möchten.
Tags und Links model-view-controller web lift