Zurück   Flashforum > Flash > ActionScript > Softwarearchitektur und Entwurfsmuster

Antwort
 
LinkBack Themen-Optionen Ansicht
Alt 24-01-2011, 09:57   #1 (permalink)
Singleton
 
Registriert seit: Mar 2009
Ort: Berlin / Hamburg
Beiträge: 497
Best Practice MVC in PureMVC

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:
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:
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!
__________________
digitale-avantgarde.com

Geändert von shredding (24-01-2011 um 10:08 Uhr)
shredding ist offline   Mit Zitat antworten
Alt 24-01-2011, 17:47   #2 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.382
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.
Omega Psi ist offline   Mit Zitat antworten
Alt 24-01-2011, 18:49   #3 (permalink)
Singleton
 
Registriert seit: Mar 2009
Ort: Berlin / Hamburg
Beiträge: 497
Zitat:
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:
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 ...
__________________
digitale-avantgarde.com

Geändert von shredding (24-01-2011 um 18:54 Uhr)
shredding ist offline   Mit Zitat antworten
Alt 24-01-2011, 19:31   #4 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.382
Nope, ein Mediator ist keine View. In PureMVC ermöglicht es die Interaktion von Views mit Modellen.
Omega Psi ist offline   Mit Zitat antworten
Alt 24-01-2011, 20:35   #5 (permalink)
Singleton
 
Registriert seit: Mar 2009
Ort: Berlin / Hamburg
Beiträge: 497
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).
__________________
digitale-avantgarde.com
shredding ist offline   Mit Zitat antworten
Antwort

Lesezeichen

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks sind an
Pingbacks sind an
Refbacks sind an


Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Best Practice - Wechsel von Schritten CrashOverwrite ActionScript 3 7 09-07-2010 11:13
PureMVC 2 UML JohnJohnson Softwarearchitektur und Entwurfsmuster 1 18-03-2010 12:04
Kommunikation zwischen Objekten - Best practice? josephtura ActionScript 3 1 18-03-2008 07:37
XML und Umlaute. Best Practice? noe Flash mit XML und Webservices 18 12-01-2007 18:47
XML und Images: Best Practice noe Flash mit XML und Webservices 2 10-07-2002 06:39


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:39 Uhr.

Domains, Webhosting & Vserver von Host Europe
Unterstützt das Flashforum!
Adobe User Group


Copyright ©1999 – 2014 Marc Thiele