Best Practice MVC in PureMVC

[shredding]

Ich arbeite mich gerade in PureMVC ein und habe nun auch schon recht viel damit experimentiert und fühle mich sicher im Konzept des Frameworks.

Da ich noch nicht soviel praxiserfahrung mit MVC habe, gibt es einige Punkte in den Best Practices, die ich nicht ganz nachvollziehen kann und bitte um eure Unterstützung.

Ich beziehe mich dabei auf die dt. Dokumentation, die leider stellenweise so wirkt, wie von Google übersetzt ...
(PureMVC - Best Practices [ German ])

1. Geschäftslogik im Controller

Zitat von Seite 21

Commands beherbergen die 'Business Logic' der Applikation.

In meinen Büchern zu Entwurfsmustern (zB Heads On Design Patterns) ist die Geschäftslogik im Modell platziert; ich habe aber auch von Varianten gelesen, die die Geschäftslogik im Controller platzieren (wie eben auch PureMVC). Das erscheint mir intuitiv auch logischer - da das Model sonst ja für zwei verschiedene Dinge zuständig wäre (Datenverwaltung + Geschäftslogik).

Welche Pro/Contra Argumente gibt es dafür, die Geschäftslogik im Controller abzubilden?

2. Mediatoren manipulieren Model

Zitat von Seite 35

Mediatoren können ungehindert auf Proxies des Models zugreifen, das Data Object über eine API lesen oder manipulieren, welche von dem Proxies ausgestellt wird.

Verletzt das nicht die Zuständigkeiten? Warum ist nicht der Controller alleinverantwortlich für die Manipulation den Models; es schafft doch unnötige Abhängigkeiten, wenn auch der Mediator das Model manipuliert, oder nicht?

3. Teile des Frameworks in View Componenten

Ich hatte es so verstanden, dass ViewComponents eigentlich keine Teile des Frameworks sind - sondern autark agierende Elemente, die erst durch Mediatoren mit dem Framework verbunden werden. Sie versenden daher ja z.B. auch keine Notifications.

Trotzdem wird in den Best Practices eine Instanz eines Value Objects (also einer Klasse aus dem Model) in einer View Component instanziiert (S. 38):

PHP-Code:


<mx:Script> 
<![CDATA[ 
      import com.me.myapp.model.vo.LoginVO;  
    // The form fields bind bidirectionally to this object’s props 
    [Bindable] public var loginVO:LoginVO = new LoginVO(); 
 ]]>
 </mx:Script> 
 
<mx:Binding source="username.text" destination="loginVO.username"/> 
<mx:Binding source="password.text" destination="loginVO.password"/ 


Hier werden die Ergebnisse eines Logins direkt in das passende Objekt des Models geschrieben.

Es irritiert mich, da hier Komplexität des Frameworks unnötigerweise in eine Komponente eingebracht wird, die eigentlich nichts davon zu wissen braucht. Schafft das nicht eine enge Kopplung, die das Framework eigentlich verhindern will?

Ich hätte erwartet, dass die View Component die Eingaben einfach (als Strings) an den Mediator weiterleitet und dann erst dieser (oder ein Command) mit einem Value Object arbeitet.

Vielen Dank für eure Meinungen!

[Omega Psi]

MVC gibt es in verschiedenen Geschmacksrichtungen. Und je nach Framework, Paradigma oder Sprache bekommst du verschiedene Sichten auf die Dinge.

1. Die Businiess Logik sollte, einfach ausgedrückt, in eigenen Klassen/Modulen gekapselt sein. Diese kann dann von Mediatoren oder eben "dem" Controller aufgerufen werden.
2. Mediatoren sind nichts anderes als Controller, die vor "den" Controller geschaltet sind. Es ist eine Frage der Komplexität und Granularität, die du abbilden möchtest.
3. Idealerweise "verschmutzt" kein Framework die einzelnen Komponenten, egal ob Model, View, Services etc.

[shredding]

Zitat von Omega Psi

Mediatoren sind nichts anderes als Controller, die vor "den" Controller geschaltet sind. Es ist eine Frage der Komplexität und Granularität, die du abbilden möchtest.

Das ist eine interessante Sichtweise. Ich hatte Mediatoren als Views interpretiert, die "hinter" den View geschaltet sind.

Zitat von Omega Psi

Idealerweise "verschmutzt" kein Framework die einzelnen Komponenten, egal ob Model, View, Services etc.

Das waren auch meine Gedanken, daher verstehe ich die Best Practice nicht. Ich werde mal im PureMVC Forum nachfragen.

EDIT: Das sind ja heftige Anforderungen, um überhaupt zum Forum zugelassen zu werden ...

[Omega Psi]

Nope, ein Mediator ist keine View. In PureMVC ermöglicht es die Interaktion von Views mit Modellen.

[shredding]

Das macht Sinn. Ich hatte sie auch nicht als View gesehen, sondern eher so als Vermittler, quasi Übersetzer View -> Framework (sie sind im Diagramm ja auch in der View angeordnet).

Aber dann verstehe ich's.

Ich manipuliere Proxies dann mit Mediatoren, wenn es um kleinere Aktionen geht, die den angeschlossenen View direkt betreffen, ansonsten nehme ich den Controller?

Wie dem auch sei, ich sammele mal ein bisschen Erfahrung, dann krieg' ich bestimmt meinen eigenen Groove mit dem Framework (das mir übrigens sehr gefällt).