Wo kann man Geschäftslogik in MVC-Design einfügen?

Ich habe eine einfache MVC-Java-Anwendung erstellt, die einer Datenbank Datensätze über Datenformulare hinzufügt.

Meine App sammelt Daten, validiert sie und speichert sie. Dies liegt daran, dass die Daten online von verschiedenen Benutzern bezogen werden. Die Daten sind meist numerischer Natur.

Nun möchte ich, dass meine App für die in der Datenbank (SQL Server) gespeicherten numerischen Daten Berechnungen durchführt und die Ergebnisse anzeigt. Der Benutzer ist nicht daran interessiert, wie Berechnungen durchgeführt werden, daher müssen sie gekapselt werden. Der Benutzer muss nur die einfachen berechneten Daten anzeigen können (z. B. A-Spaltendaten minus B-Spaltendaten geteilt durch C-Spaltendaten). Ich weiß, wie man gespeicherte Prozeduren für dieselbe schreibt, aber ich möchte eine dreistufige App.

Ich möchte die Daten, die ich als Datensatz in die Datenbank eingefügt habe, indem ich Berechnungen daran durchführe. Die ursprünglichen Daten sollten nicht betroffen sein, während die neuen Daten nach der Berechnung als neuer Entitätsdatensatz in der Datenbank gespeichert werden müssen.

Wo soll ich den Code für diese Hintergrundberechnung schreiben? Sollte ich die Regeln und die Geschäftslogik in neue JavaBeans-Dateien einfügen?

Kommentare

  • mögliches Duplikat von Während der Arbeit mit einer Datenbank OO und testbar bleiben
  • Geschäftslogik ist ein Alias für einen Mitarbeiter in Ihrem Team / Ihrer Abteilung, den Sie fragen, wie ein Modell ausgeführt werden soll. ‚ Deshalb kann die Geschäftslogik in einer separaten Klasse namens Geschäftslogik gespeichert werden. Gleiches gilt für Presentation Logic, ein Synonym für einen Designer, der Ihre Fragen zum Formatieren oder Anzeigen von UI-Komponenten beantwortet. Es kann auch eine Entwicklerlogik geben (Fragen, die Sie selbst stellen und beantworten oder die Sie Ihren Kollegen stellen), die ein Wissen darüber darstellt, wie Programmkomponenten erstellt und miteinander verbunden werden.

Antwort

Die Geschäftslogik sollte in das Feld eingefügt werden Modell , und wir sollten uns auf fette Modelle und dünne Controller .

Als Startpunkt sollten wir von der Steuerungslogik ausgehen. Beispiel: Beim Update sollte Ihr Controller Ihren Code an die Methode / den Dienst weiterleiten, die liefert Ihre Änderungen am Modell.

Im Modell können wir leicht helper / erstellen Service -Klassen, in denen die Anwendung Geschäftsregeln oder Berechnungen validiert werden kann.

Ein Konzept Zusammenfassung

  • Der Controller ist für die Anwendungslogik vorgesehen. Die Logik, die spezifisch dafür ist, wie Ihre Anwendung mit der Wissensdomäne “ “ interagieren möchte.

  • Das Modell dient zur Logik, die von der Anwendung unabhängig ist. Diese Logik sollte in allen möglichen Anwendungen der Wissensdomäne “ “ gültig sein.

  • Daher ist es logisch, alle Geschäftsregeln in das Modell einzufügen.

Kommentare

  • nette klare und prägnante Antwort ..
  • @Yusubov, können Sie mir bitte den Unterschied zwischen der Anwendungslogik und der Geschäftslogik erklären?
  • @Moh, kurz gesagt, dies sind Schlagworte, die helfen sollen Beschreiben von Technologieebenen in einer Anwendung. Geschäftslogik sind grundsätzlich Regeln des Systems gemäß Funktionsspezifikationen. Zum Beispiel muss Objekt A vom Typ B C und D zugeordnet haben, nicht jedoch E. Die Anwendungslogik ist eher eine technische Spezifikation, wie die Verwendung von Java-Servlets und OJB, um in einer Oracle-Datenbank zu bestehen.
  • Würden Sie bitte Erläutern Sie diese Wörter: The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer. [ php-html.net/tutorials/model-view-controller-in-php]
  • Wenn ich richtig verstanden habe, bezieht sich der erwähnte Artikel auf ‚ Anwendungslogik ‚ als ‚ Geschäftslogik ‚. Daher sollte alles, was sich auf die Geschäftslogik bezieht, nicht im Controller oder in der Ansicht platziert werden.

Antwort

Wie immer hängt dies von der Komplexität des Projekts ab.

In einfachen Anwendungen, in denen die Komplexität des Domänenmodells relativ gering ist, können Sie die Logik in die Modelle einfügen und als Tag bezeichnen.

Für nicht triviale Anwendungen mit komplexen Modellen und vielen Geschäftsregeln ist es jedoch besser, die Dinge ein wenig mehr zu trennen.

Wenn Sie die Geschäftslogik einfügen, die mehr als ein Modell umfasst Als Modell führen Sie eine enge Kopplung zwischen diesen Modellen ein.Da die Anwendungen weiter wachsen, verwandeln sich diese Modelle in der Regel in god models, da sie zu viel wissen. Und dies wird schnell zu einem großen Durcheinander, das schwer zu testen und zu warten ist. In diesem Fall ist es daher von Vorteil, die Logik in einer separaten Ebene zu platzieren.

Berücksichtigen Sie bei der Entscheidung über die Abstraktion immer die Komplexität und den Zweck Ihrer App und vermeiden Sie Überentwicklung. Bei trivialen / kleinen Anwendungen erhöht das Einführen von mehr Schichten als erforderlich die Komplexität, anstatt sie zu reduzieren.

Robert Martin (Onkel Bob) hat einen guten Blog-Beitrag zu diesem Thema: Die saubere Architektur.

Kommentare

  • Die Frage war spezifisch für MVC. Geschäftslogik sollte immer im Modell sein. Der Controller ist nur ein Adapter.
  • MVC ist einer der am meisten überlasteten Begriffe in der Branche. Ich möchte ‚ nicht in die Macken dieses Begriffs geraten, da dies ein Buch rechtfertigt. Die Verwendung von MVC bedeutet jedoch nicht, dass Sie

jede Logik in die Modelle einfügen müssen.

  • Aus der Definition von Steve Burbeck (Smalltalk-Team): The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Das ‚ ist eine Adapterdefinition.
  • Wenn Sie die gesamte Logik in das Modell einfügen, werden Sie Tausende von Zeilen mit nicht wartbarem Durcheinander haben. War dort. ‚ ist keine Sünde, Dienstprogrammklassen und eine Serviceschicht zu haben.
  • Ich denke, was jgauffin vorhatte, ist, dass die Frage spezifisch für MVC ist. Wenn wir uns damit einverstanden erklären, das System aus der MVC-Perspektive und nur aus der MVC-Perspektive zu betrachten, gehört die gesamte Geschäftslogik zum “ -Modell „, aber das “ -Modell “ kann mehrere Klassen und Ebenen umfassen, einschließlich “ Dienstprogrammklassen “ und “ eine Serviceschicht “ . Anders ausgedrückt, wir würden nicht ‚ sagen, dass die Serviceschicht Teil des Controllers oder der Ansicht ist, daher ist das Modell am besten geeignet.
  • Antwort

    Das Einfügen der Geschäftslogik in das Modell klingt möglicherweise am besten. Der Controller erhält einen Anruf von der Remote-Web-App. Der Controller im MVC-Webdienst nimmt den Aufruf entgegen und leitet die Ausführung an eine Methode in BL weiter. Jetzt kann Business Logic im „Modell“ enthalten sein, aber auch in einem anderen Ordner, z. B. „Business Logic“ . Es gibt also keine feste Regel, wo sich die Geschäftslogik befinden soll.

    Ich habe einen auf MVC 3.0 basierenden Webdienst verwendet, und der Container für Geschäftslogik befindet sich das MVC MODELL .

    Kommentare

    • Ich stimme zu. Sie erhalten eine viel flexiblere Anwendung, wenn Ihr Modell einfach eine Datenstruktur ist, auf die andere Geschäftslogikklassen einwirken. Als einfaches Beispiel denke ich, dass dies ein großer Fehler des Ansatzes von ASP.NET ‚ zur Validierung mithilfe von Attributen ist. Was passiert, wenn ich eine Admin-Ansicht erstelle, in der FirstName nicht erforderlich sein sollte, wenn ich die FirstName-Eigenschaft einer Person ‚ mit dem Attribut Required kommentiere? Eine Geschäftslogikschicht sollte das Modell verwenden und die geeigneten Aktionen dafür bestimmen.

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.