Model-View-Controller-Service-Paradigma/Service: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{MVC:Menü}} | {{MVC:Menü}} | ||
=Definition ([[Kowarschick (MMProg)]])= | ==Definition ([[Kowarschick (MMProg)]])== | ||
Ein [[Model-View-Controller-Service-Paradigma/Service|Service]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/service|service]]) | Ein [[Model-View-Controller-Service-Paradigma/Service|Service]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/service|service]]) | ||
einer [[Model-View-Controller-Service-Paradigma|MVCS]]-[[Anwendung]] | einer [[Model-View-Controller-Service-Paradigma|MVCS]]-[[Anwendung]] | ||
Zeile 6: | Zeile 6: | ||
[[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]] | [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]] | ||
dient zur Kommunikation | dient zur Kommunikation | ||
mit der Außenwelt, | mit der Außenwelt, {{dh}} mit Dienste-Anbietern wie [[Web-Server]]n, [[Datenbanksystem]]en oder auch [[Dateisystem]]en. | ||
Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus Modellen bzw. Datenmodulen | Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus Modellen bzw. Datenmodulen | ||
auslesen und in ein externes | auslesen und in ein externes | ||
[[Repository]] schreiben, als auch Daten aus einem externen Repository lesen und in in ein Modell bzw. Datenmodul einfügen. | [[Repository]] schreiben, als auch Daten aus einem externen Repository lesen und in in ein Modell bzw. Datenmodul einfügen. | ||
Service-Dienste können | Service-Dienste können {{iAllg}} nur von [[Model-View-Controller-Service-Paradigma/Controller|MVCS-Controllern]] | ||
bzw. [[Logic-Data-View-Controller-Service-Paradigma/Logic|LDVCS-Logik-Modulen]] sowie von anderen [[Model-View-Controller-Service-Paradigma/Service|Services]] | bzw. [[Logic-Data-View-Controller-Service-Paradigma/Logic|LDVCS-Logik-Modulen]] sowie von anderen [[Model-View-Controller-Service-Paradigma/Service|Services]] | ||
angefordert werden. | angefordert werden. | ||
Einem Service stehen in speziellen [[Model-View-Controller-Service-Paradigma/Model|MVCS-Modellen]] bzw. | Einem Service stehen in speziellen [[Model-View-Controller-Service-Paradigma/Model|MVCS-Modellen]] bzw. | ||
[[Logic-Data-View-Controller-Service-Paradigma/Data|LDVCS-Datenmodulen]] | [[Logic-Data-View-Controller-Service-Paradigma/Data|LDVCS-Datenmodulen]] {{iAllg}} {{Container}} (wie {{zB}} Arrays, ein Hash Maps, Objekte oder Änhliches) zur Verfügung, aus denen er Daten auslesen kann oder in die er Daten einfügen kann, sobald | ||
diese verfügbar sind. | diese verfügbar sind. | ||
Eventuell stehen ihm auch noch spezielle Status-Modelle bzw. -Datenmodule zur Verfügung, in denen er Statusmeldungen | Eventuell stehen ihm auch noch spezielle Status-Modelle bzw. -Datenmodule zur Verfügung, in denen er Statusmeldungen | ||
Zeile 22: | Zeile 22: | ||
<gallery perrow="3" heights="317px" widths="250px"> | <gallery perrow="3" heights="317px" widths="250px"> | ||
Datei:MVCS-Prozess 01.png|Der MVCS-Prozess | |||
Datei:LDVCS-Prozess 01.png|Der LDVCS-Prozess | |||
</gallery> | </gallery> | ||
==Eigenschaften eines Servicemoduls== | ===Eigenschaften eines Servicemoduls=== | ||
Ein Service bearbeitet eine Anfrage im Allgemeinen [[asynchron]]. Sobald ein Ergebnis in einem Modell oder Daten-Modul eingetragen wurde, kann dieses Modul den Aufrufer und beliebig viele andere Module mit Hilfe eines [[Signal]]s darüber informieren. | Ein Service bearbeitet eine Anfrage im Allgemeinen [[asynchron]]. Sobald ein Ergebnis in einem Modell oder Daten-Modul eingetragen wurde, kann dieses Modul den Aufrufer und beliebig viele andere Module mit Hilfe eines [[Signal]]s darüber informieren. | ||
Zeile 35: | Zeile 35: | ||
von speziellen Status-Modellen bzw. -Datenmodulen informiert werden. | von speziellen Status-Modellen bzw. -Datenmodulen informiert werden. | ||
Ein Service kann mehrere Anfragen hintereinander bearbeiten und dabei auch auf frühere Ergnisse (die er | Ein Service kann mehrere Anfragen hintereinander bearbeiten und dabei auch auf frühere Ergnisse (die er {{zB}} in privaten [[Zustandsvariable]]n abgelegt hat) zugreifen. In manchen Situation ist es vorteilhaft, wenn dem Aufrufer spezielle Services | ||
zur Verfügung stehen, die eingehende Service-Anfragen nicht parallel, sondern nacheinander abarbeiten. | zur Verfügung stehen, die eingehende Service-Anfragen nicht parallel, sondern nacheinander abarbeiten. | ||
=Anmerkungen= | ==Anmerkungen== | ||
Die Idee, Services als eigene Module zu betrachten, | Die Idee, Services als eigene Module zu betrachten, {{dh}} das MVC-Paradigma zu einem MVCS-Paradigma zu erweitern, | ||
geht auf Joe Berkovitz zurück.<ref>{{Quelle|Berkovitz | geht auf Joe Berkovitz zurück.<ref>{{Quelle|Berkovitz (2006)}}</ref> | ||
[[Model-View-Controller-Service-Paradigma/Service|MVCS-Services]] und | [[Model-View-Controller-Service-Paradigma/Service|MVCS-Services]] und | ||
Zeile 50: | Zeile 50: | ||
aufgerufen und LDVCS-Services werden von [[Logic-Data-View-Controller-Service-Paradigma/Logic|LDVCS-Logik-Modulen]] aufgerufen. | aufgerufen und LDVCS-Services werden von [[Logic-Data-View-Controller-Service-Paradigma/Logic|LDVCS-Logik-Modulen]] aufgerufen. | ||
In MVC-Anwendungen übernehmen | In MVC-Anwendungen übernehmen {{iAllg}} [[Model-View-Controller-Paradigma/Model|MVC-Modelle]] die Kommunikation mit der Außenwelt. | ||
Es ist aber auch denkbar, dass [[Model-View-Controller-Paradigma/Controller|MVC-Controller]] diese Aufgabe übernehmen. | Es ist aber auch denkbar, dass [[Model-View-Controller-Paradigma/Controller|MVC-Controller]] diese Aufgabe übernehmen. | ||
=Quellen= | ==Quellen== | ||
<references /> | <references /> | ||
<ol> | <ol> | ||
Zeile 59: | Zeile 59: | ||
</ol> | </ol> | ||
=Siehe auch= | ==Siehe auch== | ||
* {{Vgl|Model-View-Controller-Paradigma/Model|Model (MVC)}} | * {{Vgl|Model-View-Controller-Paradigma/Model|Model (MVC)}} | ||
* {{Vgl|Model-View-Controller-Paradigma/Controller|Controller (MVC)}} | * {{Vgl|Model-View-Controller-Paradigma/Controller|Controller (MVC)}} |
Aktuelle Version vom 31. Juli 2019, 18:00 Uhr
Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:
Korrektheit: 4 (großteils überprüft) |
Umfang: 3 (einige wichtige Fakten fehlen) |
Quellenangaben: 4 (fast vollständig vorhanden) |
Quellenarten: 4 (sehr gut) |
Konformität: 4 (sehr gut) |
Diese Bewertungen beziehen sich auf alle im nachfolgenden Menü genannten Artikel gleichermaßen.
Model (Data) | View | Controller |
|||
Definition (Kowarschick (MMProg))
Ein Service (engl. service) einer MVCS-Anwendung oder einer LDVCS-Anwendung dient zur Kommunikation mit der Außenwelt, d. h. mit Dienste-Anbietern wie Web-Servern, Datenbanksystemen oder auch Dateisystemen. Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus Modellen bzw. Datenmodulen auslesen und in ein externes Repository schreiben, als auch Daten aus einem externen Repository lesen und in in ein Modell bzw. Datenmodul einfügen.
Service-Dienste können i. Allg. nur von MVCS-Controllern bzw. LDVCS-Logik-Modulen sowie von anderen Services angefordert werden.
Einem Service stehen in speziellen MVCS-Modellen bzw. LDVCS-Datenmodulen i. Allg. Container (wie z. B. Arrays, ein Hash Maps, Objekte oder Änhliches) zur Verfügung, aus denen er Daten auslesen kann oder in die er Daten einfügen kann, sobald diese verfügbar sind. Eventuell stehen ihm auch noch spezielle Status-Modelle bzw. -Datenmodule zur Verfügung, in denen er Statusmeldungen über den aktuellen Stand und den Verlauf der Bearbeitung der Serviceanfrage eintragen kann.
Eigenschaften eines Servicemoduls
Ein Service bearbeitet eine Anfrage im Allgemeinen asynchron. Sobald ein Ergebnis in einem Modell oder Daten-Modul eingetragen wurde, kann dieses Modul den Aufrufer und beliebig viele andere Module mit Hilfe eines Signals darüber informieren. Sollte die aktuelle Anfrage nicht erfolgreich bearbeitet werden können, so kann der Service eine entsprechende Fehlermeldung in ein spezielles Fehler-Modell bzw. -Datenmodul eintragen, das dann die übrigen Module über die aufgetretenen Probleme informiert. Ebenso können anderen Module über die erfolgreiche Übertragung von Daten in die Außenwelt mit Hilfe von speziellen Status-Modellen bzw. -Datenmodulen informiert werden.
Ein Service kann mehrere Anfragen hintereinander bearbeiten und dabei auch auf frühere Ergnisse (die er z. B. in privaten Zustandsvariablen abgelegt hat) zugreifen. In manchen Situation ist es vorteilhaft, wenn dem Aufrufer spezielle Services zur Verfügung stehen, die eingehende Service-Anfragen nicht parallel, sondern nacheinander abarbeiten.
Anmerkungen
Die Idee, Services als eigene Module zu betrachten, d. h. das MVC-Paradigma zu einem MVCS-Paradigma zu erweitern, geht auf Joe Berkovitz zurück.[1]
MVCS-Services und LDVCS-Service unterscheiden sich nicht, wenn man davon absieht, dass MVCS-Services auf Modelle zugreifen und LDVCS-Services auf Datenmodule.
Die Aufrufer unterscheiden sich allerdings: MVCS-Services werden von MVCS-Controllern aufgerufen und LDVCS-Services werden von LDVCS-Logik-Modulen aufgerufen.
In MVC-Anwendungen übernehmen i. Allg. MVC-Modelle die Kommunikation mit der Außenwelt. Es ist aber auch denkbar, dass MVC-Controller diese Aufgabe übernehmen.
Quellen
- ↑ Berkovitz (2006): Joe Berkovitz; An architectural blueprint for Flex applications; https://web.archive.org/web/20070105004310/http://www.adobe.com:80/devnet/flex/articles/blueprint.html; 2006; Quellengüte: 2 (Web)
- Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)