it-swarm.com.de

ASP.NET MVC - Sollte Geschäftslogik in Controllern vorhanden sein?

Derik Whitaker hat vor ein paar Tagen einen Artikel gepostet, der einen Punkt erreicht hat, auf den ich schon seit einiger Zeit neugierig bin: Sollte Geschäftslogik in Controllern existieren?

Bisher haben alle ASP.NET MVC-Demos, die ich gesehen habe, den Repository-Zugriff und die Geschäftslogik in den Controller integriert. Einige werfen dort sogar eine Bestätigung vor. Dies führt zu ziemlich großen, aufgeblähten Controllern. Ist dies wirklich die Art und Weise, das MVC-Framework zu verwenden? Es scheint, dass dies nur dazu führen wird, dass sich viel duplizierter Code und Logik auf verschiedene Controller verteilt.

96
Kevin Pang

Geschäftslogik sollte wirklich im Modell sein. Sie sollten auf fette Models, dünne Controller abzielen.

Zum Beispiel anstatt:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Ich hätte lieber:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Dies setzt voraus, dass die Steuer von einem externen Dienst berechnet wird und dass Ihr Modell über Schnittstellen zu Ihren externen Diensten informiert ist.

Dies würde Ihren Controller ungefähr so ​​aussehen lassen:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Oder etwas ähnliches.

75
jonnii

Ich mag das Diagramm von Microsoft Patterns & Practices . Und ich glaube an das Sprichwort "Ein Bild sagt mehr als tausend Worte".

Diagram shows architecture of MVC and business sevices layers

63
AlejandroR

Sie können dieses fantastische Tutorial von Stephen Walther ansehen, das zeigt: Validierung mit einem Service-Layer .

Erfahren Sie, wie Sie Ihre Validierungslogik aus Ihren Controller-Aktionen in eine separate Service-Schicht verschieben. In diesem Lernprogramm erklärt Stephen Walther, wie Sie Bedenken scharf trennen können, indem Sie Ihre Service-Schicht von Ihrer Controller-Schicht isolieren.

14

Das ist eine faszinierende Frage.

Ich halte es für interessant, dass eine große Anzahl von MVC-Beispielanwendungen nicht dem MVC-Paradigma entspricht, da die "Geschäftslogik" tatsächlich vollständig in das Modell eingefügt wird. Martin Fowler hat darauf hingewiesen, dass MVC kein Muster im Sinne der Gang Of Four ist. Es ist vielmehr ein Paradigma, dass der Programmierer Muster hinzufügen muss bis, wenn er etwas erstellt, das über eine Spielzeug-App hinausgeht.

Die kurze Antwort lautet also, dass "Geschäftslogik" in der Tat nicht im Controller leben sollte, da der Controller die zusätzliche Funktion hat, mit der Ansicht und Benutzerinteraktionen umzugehen, und wir Objekte mit nur einem Zweck erstellen möchten.

Eine längere Antwort ist, dass Sie einige Überlegungen zum Design Ihrer Modellebene anstellen müssen, bevor Sie die Logik vom Controller zum Modell verschieben. Vielleicht können Sie die gesamte Anwendungslogik mit REST verarbeiten. In diesem Fall sollte das Design des Modells ziemlich klar sein. Wenn nicht, sollten Sie wissen, mit welchem ​​Ansatz Sie verhindern, dass Ihr Modell aufgebläht wird.

14

Business Logic sollte nicht in Controllern enthalten sein. Controller sollten so dünn wie möglich sein, idealerweise folgen Sie dem Muster:

  1. Suchen Sie die Domain-Entität
  2. Handle auf Domain-Einheit
  3. Bereiten Sie Daten für die Anzeige/Rückgabe von Ergebnissen vor

Zusätzlich können Controller einige Anwendungslogiken enthalten.

Wo lege ich meine Geschäftslogik ab? Im Modell.

Was ist Model? Das ist eine gute Frage. Bitte lesen Sie Microsoft Patterns and Practices-Artikel (ein großes Lob an AlejandroR für die hervorragende Entdeckung). Hier gibt es drei Kategorien von Modellen:

  • Ansichtsmodell : Dies ist lediglich eine Datentasche mit einer minimalen Logik, um Daten von und zu Ansichten zu übertragen, und einer grundlegenden Feldvalidierung.
  • Domänenmodell : Fettmodell mit Geschäftslogik, das auf eine oder mehrere Dateneinheiten (d. H. Einheit A in einem bestimmten Zustand als Aktion auf Einheit B) angewendet wird.
  • Datenmodell : Speicherbewusstes Modell, Logik, die in einer einzelnen Entität enthalten ist, bezieht sich nur auf diese Entität (d. H. Wenn Feld a, dann Feld b)

Natürlich ist MVC ein Paradigma, das es in verschiedenen Varianten gibt. Was ich hier beschreibe, ist, dass MVC nur die oberste Ebene belegt, vide dieser Artikel auf Wikipedia

Heutzutage sind MVC und ähnliche Model-View-Presenter (MVP) Entwurfsmuster, die sich ausschließlich auf die Präsentationsebene eines größeren Systems beziehen. In einfachen Szenarien stellt MVC möglicherweise den primären Entwurf eines Systems dar und greift direkt in die Datenbank ein. In den meisten Szenarien sind Controller und Modell in MVC jedoch in loser Abhängigkeit von einer Service- oder Datenschicht/-schicht. Hier dreht sich alles um die Client-Server-Architektur

8
Jacek Glen