Wohin geht die Geschäftslogik in MVC?

Ich glaube, Sie haben Ihre eigene Frage in einem separaten Projekt beantwortet Nicht in den Controllern und absolut nicht in den Modellen.

Edit: Beachten Sie, dass der Controller stark mit dem httpcontext gekoppelt ist, so dass es sehr klug ist, den logischen Layer in eine andere DLL-Ebene zu verschieben.

Das M in MVC ist alles, was zum Abrufen und Verarbeiten der Informationen verwendet wird, die Sie in Ihrer Anwendung verwenden. Die Business-Schicht ist daher ein Teil davon.

Ich würde einfach damit beginnen, eine separate Klassenbibliothek zu erstellen und all meine Logik darin zu speichern. Solange deine Klassen ziemlich klein sind und eine klare Verantwortung haben, ist es relativ einfach, sie später zu refaktorieren wenn Sie einen separaten Webservice benötigen (ein anderes Projekt benötigt Zugriff auf die Daten).

Normalerweise erstelle ich eine Bibliothek der dritten Klasse und lege alle Definitionen darin ab (Service-Interfaces und Domain-Modelle). Auf diese Weise folgen Sie dem getrennten Interface-Muster und machen es später noch einfacher, die Implementierung zu tauschen (und zu testen) Ihre Business-Schicht)

Sie könnten einfach einige der Geschäftslogik in eine separate c # -Klasse einfügen und sie in den Controllern referenzieren. So wurde der Code während der Web Form Tage isoliert.

Die meisten einfachen Beispiele, die ich gesehen habe, stellen eine einfache Geschäftslogik in den Controller, aber idealerweise möchten Sie vielleicht eine Business-Schicht erstellen.

Ein gutes Beispiel für die Trennung der Geschäftslogik mit MVC3 ist im Microsofts-Projekt Silk zu finden, das Sie hier herunterladen können. In dieser Lösung wird die Geschäftslogik in ein anderes Projekt als das des MVC-Projekts aufgeteilt.

In diesem Projekt können Sie sehen, dass die Steuerungslogik einfach die Kommunikation zwischen den Ansichten und den Ansichtsmodellen (Notizansichtsmodelle und nicht Business-Schicht-Modelle) behandelt. Die Ansichtsmodelle enthalten einfach die Informationen, die an die Ansichten übergeben werden. Wenn sich ein Feld in der Ansicht ändert, ändert sich daher auch das Feld im Ansichtsmodell. Das Projekt geht auch weiter, um die Ansichtsmodelle in Ansichtsmodelle zu trennen, um Daten in die Ansichten zu übertragen, und um Modelle für die Rückübertragung von Daten zu bilden, aber dies ist eine Frage der Wahl.

Dieses Projekt verwendet das Entwurfsmuster des Transaktionsskripts für seine Geschäftslogik. Der Controller übergibt Informationen an die Business-Schicht unter Verwendung seiner eigenen Ansichtsmodelle, die eine Schnittstelle in einem Befehlsmusterentwurf implementieren. Informationen, die von der Business-Schicht zurückgegeben werden, werden über die Business-Schichten-eigenen Geschäftsmodelle ausgeführt. Ich würde Ihnen wärmstens empfehlen, sich dieses Projekt anzuschauen, um besser zu verstehen, wie die Trennung erreicht wird.

Zum weiteren Lesen von Business-Schichten würde ich Ihnen auch empfehlen, einen Blick auf Wrox Enterprise .NET zu werfen, wo ein Einige der Kapitel bieten eine gute Erörterung der Optionen für die Strukturierung der Business-Schicht, von denen die erste das im Projekt Silk verwendete Transaktionsmuster ist.

Hoffe, das hilft.

Die Geschäftslogik hat in der Theorie die mittlere Stufe einer dreistufigen Architektur eingenommen.