it-swarm.com.de

Warum die Geschäftslogik in das Modell aufnehmen? Was passiert, wenn ich mehrere Speichertypen habe?

Ich habe immer gedacht, dass sich die Geschäftslogik im Controller befinden muss und dass der Controller, da er der „mittlere“ Teil ist, statisch bleibt und dass das Modell/die Ansicht über Schnittstellen gekapselt werden muss. Auf diese Weise können Sie die Geschäftslogik ändern, ohne etwas anderes zu beeinflussen, und mehrere Modelle (eines für jede Datenbank/jeden Speichertyp) und Dutzende von Ansichten (z. B. für verschiedene Plattformen) programmieren.

Jetzt lese ich in dieser Frage , dass Sie immer die Geschäftslogik in das Modell einfügen sollten und dass der Controller tief mit der Ansicht verbunden ist.

Für mich ist das nicht wirklich sinnvoll und impliziert, dass ich jedes Mal, wenn ich die Möglichkeit haben möchte, eine andere Datenbank/einen anderen Speichertyp zu unterstützen, mein gesamtes Modell einschließlich der Geschäftslogik neu schreiben muss.

Und wenn ich eine andere Ansicht möchte, muss ich sowohl die Ansicht als auch den Controller neu schreiben.

Darf jemand erklären, warum das so ist oder ob ich irgendwo falsch gelaufen bin?

71
Steffen Winkler

ElYusubovs Antwort meistens nagelt es, Domänenlogik sollte in das Modell und Anwendungslogik in den Controller gehen.

Zwei Klarstellungen:

  • Der Begriff Geschäftslogik ist hier eher nutzlos, weil er nicht eindeutig ist. Geschäftslogik ist ein Überbegriff für jede Logik, die Geschäftsleuten am Herzen liegt, und trennt sie von bloßen technischen Aspekten wie dem Speichern von Inhalten in einer Datenbank oder dem Rendern auf einem Bildschirm. Sowohl die Domänenlogik ("eine gültige E-Mail-Adresse sieht aus wie ...") als auch die Workflows/Geschäftsprozesse ("Wenn sich ein Benutzer anmeldet und nach seiner E-Mail-Adresse fragt") werden als Geschäftslogik betrachtet, wobei die erstere eindeutig zur Modell und letztere ist Anwendungslogik, die in die Steuerung geht.
  • MVC ist ein Muster zum Platzieren von Inhalten auf einem Bildschirm und zum Ermöglichen der Interaktion mit dem Benutzer. Es gibt überhaupt keinen Speicher an . Die meisten MVC-Frameworks sind Full-Stack-Frameworks, die über MVC hinausgehen und Ihnen beim Speichern Ihrer Daten helfen. Da die zu speichernden Daten normalerweise im Modell enthalten sind, bieten Ihnen diese Frameworks bequeme Möglichkeiten zum Speichern Ihres Modells. Daten in einer Datenbank, aber das hat nichts mit MVC zu tun. Im Idealfall sollten Modelle persistenzunabhängig sein und das Umschalten auf einen anderen Speichertyp sollte den Modellcode überhaupt nicht beeinflussen. Vollwertige Architekturen verfügen über eine Persistenzschicht, um dies zu bewältigen.
71
Waquo

Sie und große Teile der Programmierwelt scheinen die Rollen der MVC-Teile falsch zu verstehen. Kurz gesagt, sie sind:

Modell = Domänenlogik

Ansicht = Ausgangslogik

Controller = Eingangslogik

Dies bedeutet, dass das Modell für die gesamte Geschäftslogik verantwortlich ist: Alles, was mit dem Zeichnen von Widgets auf einem Bildschirm, dem Ansteuern eines Druckers, der Ausgabe von Daten als HTML, dem Parsen von HTTP-Anforderungen usw. usw. zusammenhängt, gehört nicht zum Modell.

Viele der modernen sogenannten "MVC" -Frameworks machen MVC jedoch überhaupt nicht oder sie kennzeichnen ihre Teile falsch. Sehr oft ist das, was als "Modell" bezeichnet wird, die Persistenzschicht des Modells, während sich die Geschäftslogik in dem befindet, was sie als "Controller" bezeichnen. Der eigentliche Controller ist normalerweise nur ein zentraler Einstiegspunkt mit einer Routing-Tabelle und etwas Code in den einzelnen "Controllern", um die empfangenen Eingaben an die richtigen Geschäftsprozesse zu senden. Was diese Frameworks als "Ansicht" bezeichnen, ist wirklich ein bisschen von allem: etwas Präsentationslogik (Ansicht), ein bisschen Eingabebehandlung und -validierung (Controller) und etwas mehr Geschäftslogik (Modell). Der Löwenanteil der tatsächlichen Ansicht wird normalerweise als "Vorlagen" bezeichnet.

Vielleicht möchten Sie auch mehr über die mehrschichtige Architektur erfahren. Während MVC eine Art Einweg ist (der Ablauf ist Controller -> Modell -> Ansicht), ist Multi-Tier eine Zwei-Wege-Sache (Präsentation -> Logik -> Daten -> Logik -> Präsentation) und einige Frameworks, die vorgeben, MVC auszuführen, führen tatsächlich drei Ebenen aus und kennzeichnen Presentation to View, Logic to Controller und Data to Model neu.

24
tdammers

Um die Geschäftslogik wirklich zu isolieren und von der Infrastruktur der Präsentationsschicht zu trennen, sollte sie von Anwendungsdiensten gekapselt werden. Die MVC-Architektur ist eine Möglichkeit, die Präsentationsschicht zu implementieren. Sie sollte in diesem Bereich verbleiben und die gesamte Geschäftslogik an diese Anwendungsdienste delegieren. Stellen Sie sich Ansichtsmodelle als Adapter zwischen der Ansicht und den Daten vor, die angezeigt und/oder gelesen werden müssen. Der Controller vermittelt die Interaktion zwischen Ansichtsmodellen, Ansichten und Anwendungsdiensten, die die Geschäftslogik hosten.

Anwendungsdienste implementieren Geschäftsanwendungsfälle und sind von der Präsentationsschicht entkoppelt, unabhängig davon, ob es sich um MVC oder etwas anderes handelt. Anwendungsdienste können wiederum Transaktionsskripte oder domänengesteuertes Design hosten.

Zur Speicherung kann der Anwendungsdienst auf ein Repository oder eine beliebige Abstraktion eines Persistenzmechanismus verweisen. Verschiedene Implementierungen können unterstützt werden, indem der Datenzugriff in eine Schnittstelle abstrahiert wird. In der Regel sind diese Abstraktionen ndicht und nur teilweise über Implementierungen hinweg portierbar. Oft ist es ein vergeblicher Versuch, eine vollständige Portabilität zu erreichen.

[~ # ~] Update [~ # ~]

Mein Vorschlag basiert auf der hexagonale Architektur . In einer hexagonalen Architektur steht Ihr Domänenmodell (Geschäftslogik) im Mittelpunkt. Dieser Kern wird von Anwendungsdiensten gekapselt, die als Fassade fungieren. Anwendungsdienste sind einfache Klassen mit Methoden, die Anwendungsfällen in Ihrer Domäne entsprechen. Eine ausführliche Beschreibung der Anwendungsdienste finden Sie unter Dienste im domänengesteuerten Design . Das Codebeispiel enthält ein PurchaseOrderService, bei dem es sich um einen Anwendungsdienst für eine Einkaufsdomäne handelt. (Beachten Sie, dass ein Anwendungsdienst nicht die Verwendung eines domänengesteuerten Designs impliziert.)

In einer hexagonalen Architektur ist eine MVC-Präsentationsschicht ein Adapter zwischen Ihrem Domänenmodell (Geschäftslogik) und einer GUI. Das Domänenmodell kennt die Präsentationsschicht nicht, aber die Präsentationsschicht kennt das Domänenmodell.

Diese Lösung hat sicherlich bewegliche Teile als eine Lösung, die Geschäftslogik in die Steuerung einfügt, und Sie sollten die Nachteile und Vorteile abwägen. Der Grund, warum ich dies vorschlage, ist, dass ich es vorziehe, die Geschäftslogik von der Präsentationsschicht zu entkoppeln, um der Komplexität entgegenzuwirken. Dies wird wichtiger, wenn die Anwendung wächst.

15
eulerfx

Kommt darauf an, was Sie unter Geschäftslogik verstehen. Jede "Logik", die dem Inhalt des Modells Bedeutung verleiht, sollte im Modell enthalten sein. In der verknüpften Frage scheint die Antwort mit der höchsten Bewertung "Geschäftslogik" als alles zu definieren, was sich auf Daten bezieht. Dies ist unter dem Gesichtspunkt sinnvoll, dass die Daten eines Unternehmens sein Geschäft sind!

Ich habe einmal ein Beispiel des Erstellers von Rails (glaube ich)) gesehen, der genau dies tat - ohne "Geschäftslogik" in das Modell aufzunehmen. Sein Beispiel war eine Controller-Klasse und -Methode für App-Registrierung und Login - Ein angegebenes Passwort im Klartext wurde verschlüsselt, bevor es in das Modell (eine Datenbank) eingefügt oder gegen dieses abgefragt wurde.

Ich kann mir kein besseres Beispiel für etwas vorstellen, das keine Controller-Logik ist und direkt in das Modell gehört.

Das Modell könnte eine Schnittstelle zu unzähligen Datenspeichern sein, um Bedenken hinsichtlich der Portabilität auszuräumen. Hier könnte man Verwirrung darüber finden, ob die Modellschnittstelle tatsächlich der "Controller" ist oder nicht.

Im Allgemeinen verknüpft der Controller das Modell und die Ansicht (die das Fleisch und die Kartoffeln der App sind). In der Kakaoentwicklung kann dies so einfach sein, dass der Controller über die XCode-GUI (Controller-Objekte und -Bindungen) verwaltet wird.

Der Abschnitt "Design Patterns" des GoF über MVC, lose zitiert:

Die MVC-Klassentriade wird zum Erstellen von Benutzeroberflächen in Smalltalk-80 verwendet. Das Modell ist das Anwendungsobjekt, die Ansicht ist die Bildschirmdarstellung und der Controller definiert, wie die Benutzeroberfläche auf Benutzereingaben reagiert. MVC entkoppelt Ansichten und Modelle, indem zwischen ihnen ein Abonnement-/Benachrichtigungsprotokoll eingerichtet wird. Das folgende Diagramm zeigt ein Modell und drei Ansichten. Der Einfachheit halber haben wir die Controller weggelassen.

Bei MVC dreht sich alles um Benutzeroberflächen. Der Fokus liegt auf dem Modell und der Ansicht - Definieren und Anzeigen von Daten. Beachten Sie das "Abonnement-/Benachrichtigungsprotokoll" - hier kommt Ihr Controller ins Spiel. Sie können alle gewünschten Ansichten erstellen. Solange sie das Protokoll einhalten, müssen Sie das Modell oder den Controller niemals berühren.

Wenn Sie speziell über Webentwicklung sprechen, sind meiner Meinung nach viele beliebte Web-Frameworks mit dem Begriff MVC und seinen Komponentendefinitionen schnell und locker.

1
Duke

Warum führen Sie keine Service-Schicht ein?

Dann ist Ihr Controller schlank und besser lesbar, dann sind alle Controller-Funktionen reine Aktionen.

Sie können die Geschäftslogik innerhalb der Serviceschicht beliebig zerlegen. Die Wiederverwendbarkeit von Code ist besser und es gibt keine Auswirkungen auf Modelle und Repositorys.

0
Anil