it-swarm.com.de

Fettmodell / dünner Controller vs. Serviceschicht

Ich entwickle seit vielen Jahren Unternehmensanwendungen mit .Net. Meine Apps haben normalerweise ein Domänenmodell, das Entitäten enthält, die SQL DB-Tabellen zugeordnet sind. Ich verwende ein Repository-Muster, eine Abhängigkeitsinjektion und eine Serviceschicht.

Vor kurzem haben wir begonnen, an MVC 3-Projekten zu arbeiten, und wir hatten eine Debatte, wo wir welche Logik platzieren sollten. Ich bin auf eine schlanke Controller/FAT-Modell-Architektur gestoßen und habe mich gefragt, wie die Service-Schicht dazu passen würde

Option 1 - Modellgespräche mit Diensten

Controller ist dünn, ruft Methoden auf den Modellen. Die Modelle "wissen", wie sie sich selbst aus der DB laden und mit Repositorys oder Services kommunizieren. Z.B. customerModel verfügt über eine Load (id) -Methode und lädt den Kunden und einige untergeordnete Objekte wie GetContracts ().

Option 2 - Controller spricht mit Diensten

Der Controller fordert die Dienste auf, Modellobjekte abzurufen. Die Logik zum Laden/Speichern usw. befindet sich in der Service-Schicht. Das Modell ist ein reines Entitätsmodell, das nur Daten enthält.

Warum ist Option 1 die bessere Wahl, insbesondere wenn es um Unternehmensanwendungen geht? Meiner Erfahrung nach sollte ich die Bedenken trennen, Modelle UND Controller so dünn wie möglich halten und spezialisierte Services für die Geschäftslogik einsetzen (siehe DB-Interaktion).

Vielen Dank für alle Ratschläge und Hinweise zu guten Ressourcen.

78

All dies hängt von der Absicht und den Anforderungen Ihrer Anwendung ab.

Das heißt, hier ist mein Vorschlag für "Mid Scale" (kein lokales Restaurant und nicht Twitter/Facebook) Web-Anwendungen.

  1. Lean Domain Modeling

    Trockene Objekte im POCO-Stil, die die MVC-Architektur Ihrer Webanwendung möglichst nicht kennen, um von Ihrer speziellen Implementierung möglichst weit entfernt zu bleiben. Möglicherweise kann sogar eine Klassenbibliothek für die Verwendung in einer externen Anwendung neu gepackt werden, z. B. über eine REST - API ein WCF-Webdienst).

    "Modell" in MVC bedeutet am genauesten das Modell, das dem Controller bekannt ist und damit das Modell, das für die Ansicht bestimmt ist.

    In kleineren (häufig als Tutorial bezeichneten) Anwendungen sind die Entitätsmodelle Ihres "Application/Domain Model Layer" häufig dieselben instanziierten Objekte, die der Controller an eine Ansicht sendet.

    In größeren Anwendungen setzen Entwickler häufig die Grundsätze der MVVM-Architektur ein und beginnen, separate View Model-Objekte zu verwenden. Die Controller rufen häufig Middle-Tier-Dienste auf, die mit den unten angezeigten Entitäten zusammenarbeiten. In diesem Szenario bedeutet das M in MVC am genauesten das Ansichtsmodell.

  2. Robust Service Layer

    Dies bedeutet nicht fettleibig Logik, sondern gut geschriebene Einzweckdienste. Das Codieren Ihrer Geschäftslogik in Diensten außerhalb des Modells ist zwar etwas "prozeduraler" als das reine "OOP", erleichtert jedoch die lose Kopplung, das Testen und die flexible Bereitstellung (z. B. Bereitstellung auf n Ebenen) erheblich.

    In meiner persönlichen Praxis codiere ich Dienste sowohl auf der Datenebene, auf der ich die Verhaltensmodellierung der POCO-Objekte (Persistenzmechanik, Validierung auf niedriger Ebene usw.) als auch auf höherer Ebene (Geschäfts-/Workflow-Funktion) näher betrachte die MVC Mechanik.

  3. Lean Controller

    Ich stelle sicher, dass mein Controller nur der Trainer ist, da es weder der Spieler (Dienste) noch der Spieler ist (Entitätsmodell oder Ansichtsmodell), sondern entscheidet einfach, wer welche Position spielt und welches Spiel zu machen ist. Meine Controller machen zwei Dinge:

    1. Rufen Sie Dienste auf, die mit den Entitäts-/Domänenmodellen interagieren

    2. Bereiten Sie ein Ansichtsmodell für die entsprechende Ansicht vor.

    Sogar authentifizierte/autorisierte Controller-Aktionen werden über injizierte Services/Attribute ausgeführt.


EDIT 1:

Beachten Sie, dass dies nicht bedeutet, dass Ihr Entitäts-/Domain-Modell anämisch ist oder sein muss. ORMs, Repositories und Fabriken, Validierung oder State Mechanics sind willkommen. Dies bedeutet nur für Anwendungen mit mittlerem Maßstab, dass Modell in MVC das Modell, das für den Controller bestimmt ist, an Ihre Ansicht übergeben wird.

Hoffentlich wird dieser Punkt die Fowler-Apostel beruhigen, die das anämische Datenmodell für ein Anti-Muster halten. Gleichzeitig spiegelt es does einen etwas prozeduralen Winkel wider als OOP, bei dem es reiner ist, Verhalten in die modellierten Klassen einzubeziehen.

Es gibt keine "ultimative Wahrheit", aber wenn Sie dieses Muster verwenden, können Sie Ihre Anwendungen einfach erstellen, testen und bereitstellen - und dabei ein hohes Maß an Wiederverwendbarkeit und Skalierbarkeit beibehalten.


EDIT 2:

Das heißt, selbst für Anwendungen mit bescheidener Größe ist es viel zu häufig, ein System über die Architektur (aus der sich ein Word-Nerd zusammensetzt?) Hinaus zu entwickeln. Zum Beispiel, ein ORM mit einem Repository-Muster zu verpacken und dann Services zu schreiben, um das Repository zu verwenden ... all dies ist gut für die Trennung von Bedenken und dergleichen, aber wenn Ihr Projekt es nicht erfordert (und es nicht sehr wahrscheinlich ist soon erfordern) solche Dinge, bauen Sie es nicht. Es ist nichts Falsches daran, das Repository insgesamt zu überspringen, Thin Business Services (z. B. Abfrageklassen) gegen einen ORM zu schreiben oder sogar Ihren Controller direkt mit ihm zu sprechen. Alles hängt vom Maßstab ab.


EDIT 3:

Ich möchte darauf hinweisen, dass diese Erklärung und dieser Rat für den Kontext der serverseitigen MVC-Architektur wie ASP.Net und nicht für clientseitige Frameworks wie Knockout oder Backbone gilt.

89

Sie müssen mehr über MVC wissen, bevor wir besprechen, wo alles abgelegt werden soll. Nun, wenn Sie dem Muster folgen möchten. Ansonsten können Sie jetzt aufhören zu lesen.

Das Muster ist sehr locker definiert. Nichts sagt aus, wie der Controller, die Ansicht oder das Modell aussehen oder wie sie strukturiert sein sollen. Das Muster gibt einfach an, dass Sie die Teile trennen und wie sie miteinander interagieren sollen. Schauen wir uns also etwas genauer an, was sie sind (meine Interpretation).

MVC

Model Das Model kann alles sein. Es kann sich um einen Webservice, Ihre Repositorys, Ihre Serviceklassen oder einfach um Ihre Domain-Modelle handeln. Das Modell ist alles, was verwendet wird, um die Informationen zu erhalten, die Sie benötigen. Betrachten Sie das "Modell" als eine Ebene anstelle eines einzelnen Objekts.

Controller Der Controller ist ein Klebstoff. Es übernimmt die Informationen aus dem Modell und passt sie an die Ansicht an und umgekehrt.

Ansicht Die Ansicht sollte nur das rendern, was der Benutzer sieht.

Beachten Sie, dass Sie das Modell nicht mit View Models verwechseln sollten. Microsoft hätte den "Model" -Ordner eigentlich "ViewModels" nennen sollen, da dies der Fall ist. Ich würde keine Informationen aus dem "Modell" direkt in den Ansichten verwenden. Andernfalls müssen Sie das Modell ändern, wenn die Ansicht geändert wird, und umgekehrt.

Die Antwort

Das Modell ist kein Ansichtsmodell, sondern eine Ebene. Alles im Modell wird verwendet, um die für die Ansicht erforderlichen Informationen abzurufen. Der Controller nimmt diese Informationen und fügt sie in ein einzelnes Ansichtsmodell ein.

Eine einzelne Controller-Aktion kann einen oder mehrere Aufrufe des "Modells" verwenden, um die von der Ansicht benötigten Informationen zusammenzustellen.

Das bedeutet, dass Ihre zweite Option die richtige ist, wenn Sie eine Anwendung erhalten möchten, die einfach zu warten und zu erweitern ist.

Beachten Sie, dass möglicherweise keine Service-Schicht erforderlich ist. Sie können den OR/M direkt von den Steuerungen aus aufrufen. Wenn Sie jedoch feststellen, dass Sie Code duplizieren oder Fat Controller erhalten, verschieben Sie die Logik einfach auf eine Serviceebene. Von dieser Änderung ist nur der Controller betroffen, da Sie die richtigen Ansichtsmodelle verwenden.

16
jgauffin

Option 1: Sie könnten das Modell == Service denken. Modellieren Sie auch IS die Business-Schicht.

Option 2 ist ein Antimuster des anämischen Domänenmodells. http://en.wikipedia.org/wiki/Anemic_domain_model

0
Imre L

Option 2 beschreibt die Architektur von Fat Stupid Ugly Controllers ( Verweis auf den Autor dieses Ausdrucks ). Diese Lösung ist im Allgemeinen gegen den MVC-Geist, da sie die Trennung von Bedenken aufhebt.

0