it-swarm-eu.dev

Wie viel Geschäftslogik sollte in der Controller-Schicht vorhanden sein?

Manchmal ist im Controller-Code unserer Anwendungen eine Geschäftslogik dargestellt. Dies ist normalerweise eine Logik, die unterscheidet, welche Methoden vom Modell aufgerufen werden sollen und/oder welche Argumente, um sie zu übergeben.

Ein weiteres Beispiel hierfür ist eine Reihe von Dienstprogrammfunktionen, die in der Steuerung vorhanden sind und möglicherweise dazu dienen, vom Modell zurückgegebene Daten gemäß einer Reihe von Geschäftsregeln zu formatieren oder zu bereinigen.

Das funktioniert, aber ich frage mich, ob es mit einer Katastrophe flirtet. Wenn die Geschäftslogik zwischen Controller und Modell geteilt wird, sind die beiden Schichten nicht mehr trennbar, und jemand, der den Code erbt, kann durch diese Ungleichmäßigkeit in der Position des Geschäftslogik-bezogenen Codes verwirrt werden.

Meine Frage ist, wie viel Geschäftslogik in der Steuerung zulässig sein soll und unter welchen Umständen, falls vorhanden?

41
jellyfishtree

Im Idealfall keine

Das ist aber nicht immer möglich. Ich kann Ihnen keine harten Zahlen wie 20% oder 10 Zeilen geben, das ist subjektiv bis zu dem Punkt, an dem es nicht beantwortet werden kann. Ich kann beschreiben, wie ich Entwurfsmuster und Umstände verwende, die ein leichtes Biegen erforderlich machen.

In meinen Augen liegt es ganz am Zweck der Anwendung. Erstellen einer einfachen REST API zum Posten? Vergessen Sie saubere Trennung oder sogar ein Muster. Sie können eine funktionierende Version in weniger als einer Stunde erstellen. Etwas Größeres erstellen? Wahrscheinlich am besten daran arbeiten.

Der Aufbau individuell enthaltener Systeme ist das Ziel. Wenn Sie anfangen, Geschäftslogik zu schreiben, die spezifisch für die Interaktion zweier Systeme ist, ist dies ein Problem. Ohne näher darauf einzugehen, kann ich keine Meinung abgeben.

Designmuster sind Formen, einige halten sich gerne strikt an sie auf der Grundlage von prinzipiellem und gut geschriebenem Code. Wenn Sie sich strikt an ein Muster halten, erhalten Sie wahrscheinlich keinen schlecht Code, aber es kann länger dauern und dazu führen, dass Sie viel mehr Code schreiben.

Designmuster sind flexibel, passen Sie sie an die Bedürfnisse von your an. Biegen Sie sie zu sehr und sie brechen trotzdem. Wissen, was Sie brauchen und wählen Sie ein Designmuster, das dem am nächsten kommt.

22
Josh K

So wenig wie möglich. Am besten keine.

Der Controller sollte sich darum kümmern, die Anforderung zu akzeptieren, den richtigen Domänendienst zur Verarbeitung der Anforderung aufzufordern und die Antwort an die richtige Ansicht weiterzugeben.

In diesem Prozess sollte die gesamte "Geschäftslogik" in den Domänendiensten vorhanden sein.

Wenn Sie über Funktionen verfügen, die Domänenobjekte übernehmen und Ansichtsmodelle daraus erstellen, kann dies vernünftigerweise mit dem Controller koexistieren. Aber das sollte Code sein, der existiert nur für die entsprechenden Ansichten. Wenn es eine Geschäftsregel für die Datenbereinigung gibt, sollte diese in Ihrer Domänen-/Serviceebene vorhanden sein (mit den entsprechenden Komponententests).

10
Eric King

Der Begriff "Geschäftslogik" ist oft verwirrend, weil die Menschen unterschiedliche Meinungen darüber haben, was dies bedeutet. Meiner Ansicht nach umfasst der Begriff "Geschäftslogik" zwei Bereiche

  • Domänenlogik
  • Anwendungslogik

Die Domänenlogik ist eine Logik, die sich auf den Kernbereich bezieht, auf den sich Ihr Unternehmen bezieht. Wenn Sie also einen Antrag für Buchhalter schreiben, sind Steuerregeln, Buchhaltungsregeln usw. Teil der Domänenlogik.

Anwendungslogik ist eine Logik, die sich auf die Tatsache bezieht, dass Sie ein Computerprogramm ausführen. Dies können Dinge wie CSV-Import-Export, Assistenten usw. sein. Kann auch Dinge wie das Erstellen vergessener Passwort-E-Mails enthalten.

Die Art von "Geschäftslogik", die Sie in die Controller-Schicht einfügen können, ist Anwendungslogik. Möglicherweise sollte nicht die gesamte Anwendungslogik dorthin gehen. Sie sollten jedoch niemals Domänenlogik in die Controller-Schicht einfügen. Das sollte natürlich in der Domänenschicht sein.

Sie haben über Logik zum Formatieren oder Bereinigen von Daten gesprochen. Die Formatierung muss auf jeden Fall Anwendungslogik sein. Die Bereinigung kann andererseits eine Domänenlogik sein, wenn die Bereinigung von Daten auf Domänenregeln basiert. Das hängt vom Kontext ab.

10
Pete

Controller sollten die Domänenlogik sehr leicht beherrschen.

Controller sollten Aufgaben delegieren, z. B. das Abrufen eines Datensatzes aus dem Datenspeicher über eine abstrahierte Service-/Repository-Schicht und das Zurückgeben von Daten an den Datenspeicher durch denselben (oder einen verwandten) Service. Die Mechanik und die Feinarbeit zwischen diesen Operationen gehören normalerweise zu einem anderen Ort als der Steuerung.

Ich stelle häufig fest, dass ich meinen Controllern Methoden zur Bereinigung kleiner Daten hinzufüge, mit denen Daten im Speicher gespeichert werden. Dies ist zwar eine effektive Lösung, passt jedoch nicht gut zur beabsichtigten Rolle des Controllers. Im Idealfall sollte alles, was Ihr Modell ändert, validiert oder analysiert, sehr nahe am Modell selbst erfolgen, wenn nicht sogar innerhalb des Modells. Wenn Sie beispielsweise ein Modellobjekt vor dem Speichern "bereinigen" müssen, sollten Sie eine SanitizeInputs () -Methode für das Modell oder als Teil des Dienstes in Betracht ziehen, der das Speichern des Modells übernimmt.

4
Nathan Taylor

Aus pragmatischer Sicht habe ich festgestellt, dass Sie entweder Logik in Ihrem Controller oder Controller-Verhalten in Ihrem Modell haben, wenn Sie versuchen, etwas zu tun, für das es keinen guten musterkonformen Ansatz gibt. Doppelt so, wenn Sie eine App schreiben, die keine große Infrastruktur hinter sich hat.

Sie können in beide Richtungen gehen, aber ich versuche normalerweise zu überlegen, ob das seltsame Bit wahrscheinlich in mehr als einer Controller-Aktion auftaucht, wenn ja, im Modell. Wenn das unklar ist, versuche ich zu überlegen, ob es an einem Ort "passender" ist als am anderen. Andernfalls füge ich es normalerweise in das Modell ein, um es vom Controller fernzuhalten (persönliche Präferenz für kleinere Controller und stärkere Datenobjekte, YMMV).

Eine dritte Möglichkeit wäre, die Utility-Elemente als separate Utility-Klasse zu bezeichnen, aber das ist nach Meinung vieler auch etwas gegen das Muster.

Nur weil Sie nicht genau einem Muster folgen, flirten Sie nicht unbedingt mit einer Katastrophe. Wenn Sie nicht wirklich erwarten, dass dieses Projekt eine erhebliche Menge an Code wiederverwendet, würde ich mir viel mehr Sorgen darüber machen, dass das Projekt für sich selbst konsistent ist (dh: Flip-Flop nicht, wo Sie diese Bits platzieren, wenn Sie einen Ort auswählen). als ein Umschreiben, das aus irgendeinem Grund einen Teil der Mitte des Projekts speichern möchte. Dokumentieren/kommentieren Sie, wo und warum Sie vom allgemeinen Muster abgewichen sind, und definieren Sie das erwartete Muster für diese Anwendung.

MVC war an einem Punkt eine Abweichung von den etablierten Mustern.

4
Bill

Wie viele andere interessante Konzepte in der Programmierung ist MVC ein leistungsfähiges Paradigma, um einer Familie enger oder ähnlicher Strategien zur Implementierung bestimmter Szenarien Struktur und Fokus zu verleihen.

Wie viele andere Programmierkonzepte vereinfacht MVC die Realität, verwirft kleine Details und bietet ein grobes Drahtmodell, dem man folgen kann. Wie viele andere Vereinfachungen der Realität hat es auch die Aufgabe, die Struktur ins Chaos zu bringen, wie sie von einem menschlichen Geist gesehen wird.

Wie viele andere Programmierkonzepte ist MVS jedoch nur eine Vereinfachung der Realität. Es ist nicht perfekt und es ist nicht gründlich. Aus diesem Grund ist es nicht möglich, ein reales Szenario in ein stark vereinfachtes Modell einzubauen. Daher stellen sich viele ähnliche Fragen.

  • Wie viel Logik sollte in eine Steuerung fließen?

  • Ob eine Ansicht eine bedingte Logik enthalten soll?

  • Ob ein Modell zusätzliche Daten enthalten sollte, die nicht direkt in Geschäftseinheiten gefunden wurden?

Dies sind alles Fragen, die sich aus dem Versuch ergeben, den Code genau und vollständig an die konzeptionelle Idee von MVC anzupassen.

Meine Antwort an Sie ist, versuchen Sie es nicht. MVC bietet Struktur. Erstellen Sie Ihre Anwendung auf dieser Grundlage, aber erwarten Sie nicht, dass sie perfekt passt. Es wird Abweichungen geben, das ist normal. Beobachten Sie einfach, um sie unter Kontrolle zu halten.

4
user8685