it-swarm.com.de

Geschäftslogik in MVC

Ich habe 2 Fragen:

Q1. Wo genau liegt "Geschäftslogik" im MVC-Muster? Ich bin verwirrt zwischen Model und Controller.

Q2. Ist "Geschäftslogik" dasselbe wie "Geschäftsregeln"? Wenn nicht, was ist der Unterschied?

Es wäre großartig, wenn Sie dies mit einem kleinen Beispiel erklären könnten.

166
hmthur

Geschäftsregeln gehen in das Modell ein.

Angenommen, Sie haben E-Mails für eine Mailingliste angezeigt. Der Benutzer klickt auf die Schaltfläche "Löschen" neben einer der E-Mails, der Controller benachrichtigt das Modell, um den Eintrag N zu löschen, und benachrichtigt dann die Ansicht, die das Modell geändert hat.

Vielleicht sollte die E-Mail des Administrators niemals von der Liste entfernt werden. Das ist eine Geschäftsregel, dass Wissen in das Modell gehört. Die Ansicht kann letztendlich darstellen diese Regel irgendwie - vielleicht macht das Modell eine "IsDeletable" -Eigenschaft verfügbar, die eine Funktion der Geschäftsregel ist, so dass die Löschschaltfläche in der Ansicht für bestimmte Einträge deaktiviert ist - aber Die Regel selbst ist nicht in der Ansicht enthalten.

Das Modell ist letztendlich der Gatekeeper für Ihre Daten. Sie sollten in der Lage sein, Ihre Geschäftslogik zu testen, ohne die Benutzeroberfläche zu berühren.

161
Mud

Faust von allem:
Ich glaube, Sie verwechseln das MVC-Muster und die n-Tier-basierten Entwurfsprinzipien.

Die Verwendung eines MVC-Ansatzes bedeutet nicht, dass Sie Ihre Anwendung nicht überlagern sollten.
Es könnte hilfreich sein, wenn Sie MVC eher als Erweiterung der Präsentationsebene sehen.

Wenn Sie Nicht-Präsentationscode in das MVC-Muster einfügen, könnte dies sehr bald zu einem komplizierten Entwurf führen.
Daher würde ich vorschlagen, dass Sie Ihre Geschäftslogik in eine separate Geschäftsschicht einordnen.

Schauen Sie sich das an: Wikipedia-Artikel über mehrschichtige Architektur

Es sagt:

Heutzutage sind MVC und ähnliche Model-View-Presenter (MVP) Entwurfsmuster, die ausschließlich für die Präsentationsebene eines größeren Systems gelten.

Wie auch immer ... Wenn es sich um eine Unternehmens-Webanwendung handelt , sollten die Aufrufe der Benutzeroberfläche an die Geschäftslogik-Ebene innerhalb des (Präsentations-) Controllers platziert werden.

Dies liegt daran, dass der Controller die Aufrufe einer bestimmten Ressource tatsächlich verarbeitet, die Daten durch Aufrufen der Geschäftslogik abfragt und die Daten (das Modell) mit der entsprechenden Ansicht verknüpft.

Mud hat dir gesagt, dass die Geschäftsregeln in das Modell einfließen.
Das stimmt auch, aber er hat das (Präsentations-) Modell (das 'M' in MVC) und das Datenschichtmodell eines tier-basierten Anwendungsdesigns verwechselt.
Es ist also gültig, Ihre datenbankbezogenen Geschäftsregeln im Modell (Datenschicht) Ihrer Anwendung zu platzieren.
Sie sollten sie jedoch nicht in das Modell Ihrer MVC-strukturierten Präsentationsebene einfügen, da dies nur für eine bestimmte Benutzeroberfläche gilt.

Diese Technik ist unabhängig davon, ob Sie ein domänengesteuertes Design oder einen transaktionsskriptbasierten Ansatz verwenden.

Lassen Sie mich das für Sie visualisieren:


Präsentationsebene: Modell - Ansicht - Controller


Geschäftsschicht: Domänenlogik - Anwendungslogik


Datenschicht: Datenrepositorys - Datenzugriffsschicht


Das oben gezeigte Modell bedeutet, dass Sie eine Anwendung haben, die MVC, DDD und eine datenbankunabhängige Datenschicht verwendet.
Dies ist ein gängiger Ansatz zum Entwerfen einer größeren Unternehmens-Webanwendung.

Sie können es aber auch verkleinern, um eine einfache Nicht-DDD-Geschäftsschicht (eine Geschäftsschicht ohne Domänenlogik) und eine einfache Datenschicht zu verwenden, die direkt in eine bestimmte Datenbank schreibt.
Sie können sogar die gesamte Datenschicht löschen und direkt von der Geschäftsschicht aus auf die Datenbank zugreifen, obwohl ich dies nicht empfehle.

Das ist der Trick ... Ich hoffe das hilft ...

[Anmerkung:] Sie sollten sich auch der Tatsache bewusst sein, dass eine Anwendung heutzutage mehr als nur ein "Modell" enthält. In der Regel hat jede Ebene einer Anwendung ein eigenes Modell. Das Modell der Präsentationsebene ist ansichtsspezifisch, jedoch häufig unabhängig von den verwendeten Steuerelementen. Die Geschäftsschicht kann auch ein Modell haben, das als "Domänenmodell" bezeichnet wird. Dies ist normalerweise der Fall, wenn Sie sich für einen domänenbasierten Ansatz entscheiden. Dieses "Domain-Modell" enthält sowohl Daten als auch Geschäftslogik (die Hauptlogik Ihres Programms) und ist in der Regel unabhängig von der Präsentationsschicht. Die Präsentationsschicht ruft normalerweise die Geschäftsschicht bei einem bestimmten "Ereignis" (Drücken einer Taste usw.) auf, um Daten aus der Datenschicht zu lesen oder in die Datenschicht zu schreiben. Die Datenschicht verfügt möglicherweise auch über ein eigenes Modell, das in der Regel datenbankbezogen ist. Es enthält häufig eine Reihe von Entitätsklassen sowie Datenzugriffsobjekte (DAOs).

Die Frage ist: Wie passt das zum MVC-Konzept?

Antwort -> tut es nicht!
Nun - das tut es irgendwie, aber nicht vollständig.
Dies liegt daran, dass MVC ein Ansatz ist, der Ende der 1970er Jahre für die Programmiersprache Smalltalk-80 entwickelt wurde. Zu dieser Zeit waren GUIs und PCs ziemlich ungewöhnlich und das World Wide Web wurde noch nicht einmal erfunden! Die meisten heutigen Programmiersprachen und IDEs wurden in den 1990er Jahren entwickelt. Zu dieser Zeit waren Computer und Benutzeroberflächen völlig anders als in den 1970er Jahren.
Denken Sie daran, wenn Sie über MVC sprechen.
Martin Fowler hat einen sehr guten Artikel über MVC, MVP und die heutigen GUIs geschrieben.

172
Frank

Der Begriff Geschäftslogik ist meiner Meinung nach keine genaue Definition. Evans spricht in seinem Buch Domain Driven Design über zwei Arten von Geschäftslogik:

  • Domänenlogik.
  • Anwendungslogik.

Diese Trennung ist meiner Meinung nach viel deutlicher. Und mit der Erkenntnis, dass es verschiedene Arten von Geschäftsregeln gibt, geht auch die Erkenntnis einher, dass nicht alle notwendigerweise am selben Ort ablaufen.

Domänenlogik ist eine Logik, die der tatsächlichen Domäne entspricht. Wenn Sie also eine Buchhaltungsanwendung erstellen, sind Domänenregeln Regeln für Konten, Buchungen, Steuern usw. In einem agilen Software-Planungstool sind die Regeln beispielsweise das Berechnen von Veröffentlichungsterminen auf der Grundlage der Geschwindigkeit und der Story Points im Backlog. etc.

Für beide Arten von Anwendungen kann der CSV-Import/-Export relevant sein, die Regeln für den CSV-Import/-Export haben jedoch nichts mit der tatsächlichen Domäne zu tun. Diese Art von Logik ist Anwendungslogik.

Die Domänenlogik geht mit Sicherheit in die Modellschicht. Das Modell würde auch der Domänenschicht in DDD entsprechen.

Die Anwendungslogik muss jedoch nicht unbedingt in der Modellebene platziert werden. Dies kann direkt in den Controllern erfolgen, oder Sie können eine separate Anwendungsebene erstellen, die diese Regeln hostet. Was in diesem Fall am logischsten ist, hängt von der tatsächlichen Anwendung ab.

70
Pete

A1 : Business Logic geht zum Teil Model in MVC. Die Rolle von Model besteht darin, Daten und Geschäftslogik zu enthalten. Controller ist andererseits dafür verantwortlich, Benutzereingaben zu erhalten und zu entscheiden, was zu tun ist.

A2 : A Business Rule ist ein Teil von Business Logic. Sie haben ein has a Beziehung. Business Logic hat Business Rules.

Schauen Sie sich Wikipedia entry for MVC . Gehen Sie zur Übersicht, wo der Ablauf des Musters MVC erwähnt wird.

Siehe auch Wikipedia entry for Business Logic . Es wird erwähnt, dass Business Logic besteht aus Business Rules und Workflow.

26
decyclone

Dies ist eine beantwortete Frage, aber ich gebe meinen "einen Cent":

Geschäftsregeln gehören in das Modell. Das "Modell" besteht immer aus (logisch oder physikalisch getrennt):

  • Präsentationsmodell - eine Reihe von Klassen, die für die Verwendung in der Ansicht gut geeignet sind (sie sind auf eine bestimmte Benutzeroberfläche/Präsentation zugeschnitten),
  • Domänenmodell - der von der Benutzeroberfläche unabhängige Teil des Modells und
  • Repository - Der speicherbewusste Teil des "Modells".

Geschäftsregeln leben im Domain-Modell, sind dem "Presentation" -Modell in einer darstellungsgerechten Form ausgesetzt und werden manchmal in der "Data Layer" dupliziert (oder auch erzwungen).

15
G. Stoynev

Wie einige Antworten gezeigt haben, gibt es meines Erachtens einige Missverständnisse zwischen der Multi-Tier- und der MVC-Architektur.

Bei einer mehrstufigen Architektur wird Ihre Anwendung in Ebenen unterteilt (z. B. Präsentation, Geschäftslogik, Datenzugriff).

MVC ist ein Architekturstil für die Präsentationsebene einer Anwendung. Für nicht triviale Anwendungen sollte Geschäftslogik/Geschäftsregeln/Datenzugriff nicht direkt in Modelle, Ansichten oder Controller platziert werden. Dies würde bedeuten, dass Geschäftslogik in Ihre Präsentationsschicht eingefügt wird und somit die Wiederverwendung und Wartbarkeit Ihres Codes verringert wird.

Das Modell ist eine sehr vernünftige Wahl für die Platzierung von Geschäftslogik. Ein besserer und besser zu wartender Ansatz besteht jedoch darin, die Präsentationsschicht von der Geschäftslogikschicht zu trennen und eine Geschäftslogikschicht zu erstellen und die Geschäftslogikschicht bei Bedarf einfach aus Ihren Modellen aufzurufen. Die Geschäftslogikschicht ruft wiederum die Datenzugriffsschicht auf.

Ich möchte darauf hinweisen, dass es nicht ungewöhnlich ist, Code zu finden, der Geschäftslogik und Datenzugriff in einer der MVC-Komponenten mischt, insbesondere wenn die Anwendung nicht mit mehreren Ebenen erstellt wurde. In den meisten Unternehmensanwendungen finden Sie jedoch häufig mehrschichtige Architekturen mit einer MVC-Architektur in der Präsentationsebene.

10
treefiddy

Es ist nicht sinnvoll, Ihre Business-Schicht in das Modell für ein MVC-Projekt aufzunehmen.

Angenommen, Ihr Chef beschließt, die Präsentationsebene auf etwas anderes zu ändern, dann wären Sie fertig! Die Business-Schicht sollte eine separate Assembly sein. Ein Modell enthält die Daten aus der Business-Schicht, die zur Anzeige an die Ansicht übergeben werden. Beim Posten wird das Modell beispielsweise an eine Person-Klasse gebunden, die sich in der Business-Schicht befindet und PersonBusiness.SavePerson (p) aufruft. Dabei ist p die Personenklasse. Ich mache Folgendes (die BusinessError-Klasse fehlt, würde aber auch in BusinessLayer verwendet werden): enter image description here

4
Alex

Q1:

Geschäftslogiken können in zwei Kategorien unterteilt werden:

  1. Domänenlogiken wie die Steuerung einer E-Mail-Adresse (Eindeutigkeit, Einschränkungen usw.), das Abrufen des Preises eines Produkts für die Rechnung oder das Berechnen des Gesamtpreises des Warenkorbs anhand seiner Produktobjekte.

  2. Umfangreichere und kompliziertere Workflows, die als Geschäftsprozesse bezeichnet werden, z. B. die Steuerung des Registrierungsprozesses für den Studenten (der normalerweise mehrere Schritte umfasst, unterschiedliche Prüfungen erfordert und komplexere Einschränkungen aufweist).

Die Kategorie first geht in model und die Kategorie second one gehört zu Controller . Dies liegt daran, dass es sich bei den Fällen in der zweiten Kategorie um umfassende Anwendungslogiken handelt und das Einfügen in das Modell möglicherweise die Abstraktion des Modells vermischt (z. B. ist nicht klar, ob wir diese Entscheidungen in die eine oder andere Modellklasse einfügen müssen, da sie miteinander zusammenhängen) an beide!).

Siehe diese Antwort für eine spezifische Unterscheidung zwischen Modell und Steuerung, diese Link für sehr genaue Definitionen und auch diese Link für ein Nizza Android Beispiel.

Der Punkt ist, dass die von "Mud" und "Frank" oben erwähnten Notizen sowohl wahr als auch "Pete" sein können (Geschäftslogik kann je nach Art der Geschäftslogik in ein Modell oder einen Controller eingefügt werden).

Beachten Sie schließlich, dass MVC von Kontext zu Kontext unterschiedlich ist. Zum Beispiel werden in Android -Anwendungen) einige alternative Definitionen vorgeschlagen, die sich von den webbasierten unterscheiden (siehe dies post zum Beispiel).


Q2:

Die Geschäftslogik ist allgemeiner und (wie oben unter "decyclone" erwähnt) haben wir die folgende Beziehung zwischen ihnen:

geschäftsregeln ⊂ Geschäftslogik

1
Alisa