Remote Presentation Model
# Remote Presentation Model

Das Remote Presentation Model (RPM) ist ein Architekturmuster zur Strukturierung von Software-Entwicklung. Es wird vor allem in einer Client-Server Infrastruktur genutzt und dient wie das MVC Muster dazu, eine Trennung zwischen View (UI) und der Controller bzw. Business-Logik zu erstellen. Ähnlich wie beim MVC Muster findet auch hier eine Trennung zwischen Model, View und Controller Logik statt. Anders als beim MVC Muster definiert das Remote Presentation Model allerdings zusätzlich eine Trennung der Komponenten zwischen Client und Server. Hierbei liegt der Controller Part im Server und bietet den Vorteil serverseitige Technologien (APIs, Frameworks etc.) zu nutzen. Zusätzlich wird der View Layer durch die Nutzung des Remote Presentation Model Musters besonders leichtgewichtig und kann deutlich einfacher als bei anderen Architekturmustern ausgetauscht werden.

## Aufbau des Remote Presentation Model Musters

Wie aus MVC bekannt teilt sich auch das Remote Presentation Model Muster in die drei Bestandteile Model, View und Controller auf. Hierbei definiert das Remote Presentation Model aber die Abhängigkeiten und Schnittstellen zwischen den drei Komponenten deutlich strikter als das MVC Muster.

### Model

Das Model ist sowohl im serverseitigen Controller als auch in der clientseitigen View bekannt. Daher gibt es eine serverseitige und eine clientseitige Instanz des Models, welche synchron gehalten werden müssen. Als Best Practice sollte das Model das Observer Pattern unterstützen um die Programmierung in der View und im Controller deutlich zu vereinfachen. Da der Aufbau des Models in der Regel durch die in der View darzustellenden Werte definiert wird, benutzt man auch oft den Begriff "Presentation Model" (siehe zum Vergleich das ViewModel in MVVM).

### View

Die View ist als möglichst flacher Layer ohne Business- und Controller-Logik definiert. Grundsätzlich werden in der View die Werte des Models an Werte der Benutzeroberfläche gebunden. Ein Text Wert im Model kann so z. B. an den Eingabetext eines Textfeldes gebunden werden. Hier sollen in der Regel Änderungen im Model die View aktualisieren und Änderungen in der View (z. B. durch Benutzereingaben) das Model aktualisieren. Durch die Unterstützung des Observer Pattern und Data Binding im Model kann dies deutlich vereinfacht werden.

### Controller

Der Controller definiert die gesamte Logik. Hier werden die initialen Werte des Models definiert und auf Änderungen im Model reagiert. Da der Controller im Server definiert wird, können hier auch serverseitige Technologien zum Einsatz kommen. So kann man Änderungen im Model zum Beispiel direkt in eine zentrale Datenbank speichern.

