Ich denke, dass Geschäftslogik in einem Modell vorhanden sein sollte, wenn ein MVC- oder MVP-Entwurfsmuster verwendet wird, aber hinter einem Service in einer serviceorientierten Architektur verborgen werden sollte.
Kann ein Softwaresystem das MVC- oder MVP-Entwurfsmuster in einer serviceorientierten Architektur verwenden? Wenn ja, wo sitzt das Modell?
Nun, sie sind total verschiedene Tiere. MVC dreht sich alles um Präsentation von Daten, Steuerung der Navigation des Benutzerdialogs und einige Geschäftslogik beim Aufbau des Datenmodells.
Bei SOA geht es darum, Daten von einem Dienstanbieter abzurufen.
Auf der Clientseite können Sie SOA innerhalb des Model-Teils des MVC-Musters verwenden, um Ihr Modell mit Daten von einem SOA-Service aufzubauen.
Da auf der Serviceseite keine Präsentation und kein Benutzerdialog vorhanden ist, wird das MVC-Muster größtenteils überflüssig. Darüber hinaus sollte sich ein gutes SOA-Design auf die Bereitstellung eines nützlichen Dienstes konzentrieren, unabhängig vom zugrunde liegenden Datenspeicher, sodass der "Modell" -Teil weitgehend nebensächlich wird.
Es ist wahr, dass viele Dienste "stateful" sind (zB Aufträge werden validiert, bezahlt, versendet und dann empfangen), aber diese Zustände sind ein integraler Bestandteil der Geschäftslogik und eignen sich nicht für das typische Sitzungsmanagement das MVC-Muster.
Gute Frage. Ich denke MVC und SOA werden und müssen koexistieren. MVC ist die erfolgreichste Architektur für die Benutzer-zu-System-Kommunikation. SOA ist eine Architektur für effektive System-System-Kommunikation. In den meisten Organisationen gibt es einen Platz für beide. Deshalb glaube ich, dass sie nebeneinander bestehen werden.
In Bezug darauf, wie sie miteinander interagieren, ist meine persönliche Meinung: MVC wird (sobald der SOA-Hype verschwunden ist) als das Kernarchitekturmuster beibehalten, wobei sowohl das Modell als auch der Controller die Serviceschnittstellen freilegen.
Tags und Links model-view-controller mvp architecture soa