Model-View-Controller-Service-Paradigma
MVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg))
gerahmt | rechts | Besipiel für eine VCSM-Schichtenarchitektur
VCSM-Paradigma
Ein MVCS-Paradigma wird VCSM-Paradigma genannt, wenn die vier zugehörigen Module folgende Schichtenarchitektur bilden: View, Controller, Service, Model.
Die vier Module einer MVCS-Komponente sind gemäß dem Layer-Pattern in Ebenen angeordnet. Die höheren Ebenen können auf tiefergelegene Ebenen zugreifen, aber nicht umgekehrt.
Die unserste Ebene enthält das Modell. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit indirekt – z.B. durch Antworten auf Nachrichten oder mit Hilfe des Observer-Patterns – kommunizieren.
Ein Servicemodul kennt nur die darunterliegende Modelle und kann nur auf diese zugreifen (sowie i. Allg. auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt).
Ein Controllermodul kann entweder direkt auf ein Modellmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel um Daten aus einer externen Quelle zu laden, oder um zu überprüfen, ob die entsprechenden Zugriffsrechte für eine Datenmanipulation überhaut gegeben sind).
Man beachte, dass in diesem Paradigma die Logik der Anwendung in den Controllern und nicht in den Modellen realisiert werden sollte, da die Modelle keinen direkten Zugriff auf andere Module haben.
Eine View kommuniziert i. Allg. direkt nur mit Controllermodulen, um diesen Benutzeraktionen, die über die View erfolgen, mitzuteilen. Ein direkter Zugriff auf ein Datenmodul ist nur dann notwendig, wenn die Nachrichten, die von den Datenmodulen verschickt werden, nicht alle relevanten Informationen enthalten. Zugriffe auf Servicemodule sind nicht vorgesehen.
Der Benutzer stellt das „oberste Modul“ dar. Er kommuniziert nur mit View- und Controllermodulen.
gerahmt | rechts | Besipiel für eine CVMS-Schichtenarchitektur
CVMS-Paradigma
Ein MVCS-Paradigma wird CVMS-Paradigma genannt, wenn die drei zugehörigen Module folgende Schichtenarchitektur bilden: Controller, View, Model und Service.
Die Controller-Module können direkt (z.B. via Unicast-Nachrichten) auf die View- und Modell-Module zugreifen, die View-Module können direkt auf Modell-Module zugreifen und die Modell-Module können direkt mit Service-Modulen kommunizieren, um Daten mit externen Repositories auszutauschen. Alle anderen „Zugriffe“ erfolgen nur indirekt (i. Allg. als Antworten auf Unicast-Nachrichten, evtl. auch mittels Callback-Routinen).
Man beachte, dass in diesem Paradigma die Logik der Anwendung in den Controllern und nicht in den Modellen realisiert werden sollte, da die Modelle keinen direkten Zugriff auf andere Module haben.
MVCS-Multicast-Paradigma
Ein MVCS-Paradigma wird MVCS-Multicast-Paradigma genannt, wenn alle Module nur indirekt, d.h. mit Hilfe von Multicast-Nachrichten kommunizieren.
