Was sind die Einschränkungen für den Controller in MVC?

Question

Sollte der Controller direkte Zuweisungen an die Modellobjekte vornehmen oder dem Modell lediglich mitteilen, was zu tun ist?

Answer 1

Der Kontrolleur hat zwei traditionelle Aufgaben:

1. Behandlung des Eingabeereignisses von der Benutzeroberfläche (registrierter Handler oder Callback)

2. Benachrichtigung des Modells über eine Aktion, die zu einer Änderung des Zustands des Modells führen kann oder nicht

Sie führt keine Datenvalidierung durch, das ist Sache des Modells, und sie hat auch kein Mitspracherecht bei der Darstellung der Informationen.

Answer 2

Das hängt weitgehend vom Umfang Ihrer Anwendung ab. Wenn es sich um eine relativ schnelle und schmutzige Anwendung handelt, dann macht es keinen Sinn, zu viel zu entwickeln, und natürlich können Ihre Controller mit Ihren Modellobjekten kommunizieren. Wenn es andererseits aus irgendeinem Grund "unternehmensgerechter" sein soll, ist ein gutes Muster für die Verwendung in Verbindung mit MVC der so genannte "Business Delegate". Hier können Sie grobkörnige Methoden aus einer oder mehreren Methoden für ein oder mehrere Modellobjekte zusammenstellen, z. B. ein Objekt löschen und dann eine aktualisierte Liste ohne dieses Objekt zurückgeben. Diese Schicht bietet zwei Vorteile. Zum einen entkoppelt sie die Controller von dem ORM-System, das für die Modellobjekte verwendet wird. Zum anderen ist es die Schicht, die sich schließlich konstruktiv mit eventuell aufgetretenen Ausnahmen befassen muss, anstatt sie erneut auszulösen.

Answer 3

Ich glaube nicht, dass ein Controller mit Modellobjekten zu tun haben sollte.

Ich neige dazu zu denken, dass Controller wirklich Teil der UI-Ebene ist. Ich ziehe es vor, eine Serviceschicht zwischen dem Controller und dem Rest der App einzubauen. Die Webebene nimmt HTTP-Anfragen entgegen, wandelt Parameter von Anfrageobjekten in Objekte um, mit denen die Serviceschnittstelle umgehen kann, und wandelt die Antwort zum Zurücksenden um. Die gesamte Arbeit mit Transaktionen, Arbeitseinheiten und der Umgang mit Modell- und Persistenzobjekten wird vom Dienst erledigt.

Dieser Ansatz ist stärker dienstleistungsorientiert. Er trennt den Dienst von der Benutzeroberfläche und lässt die Möglichkeit offen, dass mehrere Kunden denselben Dienst wiederverwenden können. Er macht die Schicht, die Anfragen an den Dienst weiterleitet, "dünn", so dass es einfach ist, SOAP-Dienste gegen REST oder EJB oder CORBA oder was auch immer das nächste neue Ding sein wird, auszutauschen.

Answer 4

Die Modelldienste müssen die Existenz des Controllers nicht kennen, so dass der Controller die Dinge tun kann, die die Ansicht benötigt, indem er die Modelldienste nutzt.