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 größtenteils numerischer Natur.

Nachdem die numerischen Daten in der Datenbank (SQL Server) gespeichert wurden, möchte ich, dass meine App Berechnungen durchführt und die Ergebnisse anzeigt. Der Benutzer ist nicht daran interessiert, wie Berechnungen durchgeführt werden, so dass sie gekapselt werden müssen. Der Benutzer muss nur die einfach berechneten Daten anzeigen können (z. B. A-Spaltendaten minus B-Spaltendaten geteilt durch C-Spaltendaten). Ich kann gespeicherte Prozeduren für dasselbe schreiben, aber ich möchte eine dreistufige App.

Ich möchte, dass die Daten, die ich als Datensatz in die Datenbank gestellt habe, durch Berechnungen bearbeitet werden. Die ursprünglichen Daten sollten nicht betroffen sein, während die neuen Daten, Nachberechnungen, 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?

— BriskLabs Pakistan
quelle

mögliches Duplikat von Staying OO und Testable während der Arbeit mit einer Datenbank

— Mücke

Antworten:

Die Geschäftslogik sollte im Modell platziert werden , und wir sollten auf fette Modelle und dünne Controller abzielen .

Als Ausgangspunkt sollten wir von der Steuerungslogik ausgehen. Zum Beispiel: auf Update sollten Sie Ihre Controller Ihren Code an die direkte Methode / Service , der liefert Ihre Änderungen an dem Modell.

Im Modell können leicht Helfer- / Serviceklassen erstellt werden, in denen die Geschäftsregeln oder Berechnungen der Anwendung validiert werden können.

Eine konzeptionelle Zusammenfassung

Die Steuerung ist für die Anwendungslogik. Die Logik, die spezifisch dafür ist, wie Ihre Anwendung mit der zugehörigen "Wissensdomäne" interagieren soll.
Das Modell ist für eine von der Anwendung unabhängige Logik . Diese Logik sollte in allen möglichen Anwendungen des "Wissensbereichs" gültig sein, zu dem sie gehört.
Daher ist es logisch, alle Geschäftsregeln im Modell zu platzieren.

— EL Yusubov
quelle

— Schöne,

@ Yusubov, könnten Sie mir bitte den Unterschied zwischen der Anwendungslogik und der Geschäftslogik erklären

— Mohamad

@Moh, Kurz gesagt, dies sind Schlagworte, die bei der Beschreibung von Technologieebenen in einer Anwendung hilfreich sind. Geschäftslogik ist im Grunde Regeln des Systems nach funktionalen Vorgaben. Zum Beispiel muss Objekt A vom Typ B C und D zugewiesen haben, nicht jedoch E. Application Logic ist eher eine technische Spezifikation, wie die Verwendung von Java-Servlets und OJB, um in einer Oracle-Datenbank zu verbleiben.

— EL Yusubov,

Würden Sie bitte auf diese Wörter näher

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

— eingehen

Wenn ich richtig verstanden habe, bezieht sich der erwähnte Artikel auf "Anwendungslogik" als "Geschäftslogik". Daher sollte nichts, was sich auf die Geschäftslogik bezieht, in der Steuerung oder in der Ansicht platziert werden.

— EL Yusubov

Wie immer kommt es auf die Komplexität des Projekts an.

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

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

Wenn Sie die Geschäftslogik, an der mehr als ein Modell beteiligt ist, in ein Modell aufnehmen, führen Sie eine enge Kopplung zwischen diesen Modellen ein. Da die Anwendungen immer größer werden, entwickeln sich diese Modelle zu einem Modell god models, das zu viel weiß. Und dies wird schnell zu einem großen Durcheinander, das schwer zu testen und zu warten ist. In diesem Fall ist es vorteilhaft, die Logik in einer separaten Ebene abzulegen.

Berücksichtigen Sie bei der Entscheidung für eine Abstraktion immer die Komplexität und den Zweck Ihrer App und vermeiden Sie Überentwicklungen. Bei einfachen / kleinen Anwendungen erhöht die Einführung von mehr Schichten als erforderlich die Komplexität, anstatt sie zu reduzieren.

Robert Martin (Onkel Bob) hat einen guten Blogbeitrag zu diesem Thema: The Clean Architecture.

— Hakan Deryal
quelle

Die Frage war spezifisch für MVC. Geschäftslogik sollte immer im Modell sein. Der Controller ist nur ein Adapter.

— Jgauffin

MVC ist einer der am meisten überlasteten Begriffe in der Branche. Ich möchte nicht in die Macken dieses Begriffs geraten, da es ein Buch rechtfertigt. Die Verwendung von MVC bedeutet jedoch nicht, dass Sie jede Logik in die Modelle einfügen müssen.

— Hakan Deryal

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.

— jgauffin

Wenn Sie die gesamte Logik in das Modell einbauen, werden Sie Tausende von Zeilen mit nicht zu wartendem Durcheinander hinterlassen. War dort. Es ist keine Sünde, Utility-Klassen und eine Service-Schicht zu haben.

— Asthasr

Ich denke, was jgauffin damit anfing, ist, dass die Frage spezifisch für MVC ist. Wenn wir das System zu betrachten , aus der MVC Perspektive und nur die MVC Perspektive übereinstimmen, dann ja, alle von der Geschäftslogik gehören im „Modell“, sondern das „Modell“ kann umfasst mehrere Klassen und Schichten, darunter „Utility - Klassen“ und msgstr "eine Serviceschicht". Anders ausgedrückt, wir würden nicht sagen, dass die Service-Schicht ein Teil des Controllers oder der Ansicht ist, daher ist das Modell am besten geeignet.

— DavidS

Das Einfügen der Geschäftslogik in das Modell scheint der beste Weg zu sein. 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 'Model' enthalten sein, aber auch in einem anderen Ordner, beispielsweise 'Business Logic' . Es gibt also keine feste Regel, wo sich die Geschäftslogik befinden soll.

Ich habe einen Webdienst verwendet, der auf MVC 3.0 basiert, und der Container der Geschäftslogik ist das MVC- MODELL .

— Monty Python
quelle

Genau. Sie erhalten eine viel flexiblere Anwendung, wenn Ihr Modell lediglich eine Datenstruktur ist, auf die andere Geschäftslogikklassen reagieren. Als einfaches Beispiel denke ich, dass dies ein schwerwiegender Fehler des ASP.NET-Ansatzes zur Validierung mithilfe von Attributen ist. Was passiert, wenn ich die FirstName-Eigenschaft einer Person mit dem Required-Attribut beschrifte, wenn ich eine Admin-Ansicht erstelle, in der FirstName nicht erforderlich sein sollte? Eine Geschäftslogikschicht sollte das Modell konsumieren und die entsprechenden Aktionen dafür festlegen.

— xr280xr