[Erledigt] Model-View Konzeption

[-UFO-]Melkor · 08.06.2011, 01:35

Ich stehe im Moment vor dem Problem, wie ich mein Model und meine View miteinander verbinden kann. Ich will versuchen, es an einem einfach gehaltenem Beispiel deutlich zu machen:

Das Domain-Model:

PHP-Code:

  class Member implements User

{

    //...

}

 
class Guest implements User

{

    //...

}

 
interface User

{

    public function getId();

    public function getName();

    public function getEmailAddress();

}

 
class Thread

{

    public function getAuthor();

    public function getName();

}

 
class ImportantThread extends Thread

{

}

Der View übergebe ich nun die jeweiligen Objekte. Dort möchte ich nun auf die verschiedenen Arten von Objekten reagieren:

Ein ImportantThread soll ein anderes Bild als ein Thread bekommen.
Ein Member soll verlinkt werden, ein Guest nicht.

Wie komme ich nun darum herum, in meiner View ständig if-else- oder switch-Konstrukte verwenden zu müssen? Ein paar Ansätze habe ich, aber so wirklich gefallen tun sie mir alle nicht.

Entscheidung ins Model verlagern
Eine Möglichkeit wäre es, der Klasse Thread z.B. eine getImageSource-Methode zu verpassen, die dann von dem ImportantThread überschrieben werden könnte. Allerdings ist dies ein Wissen, welches das Model gar nicht haben sollte (je nach View mag es verschiedene Bilder geben). Von daher klingt dieser Ansatz für mich nicht sehr klug.

Eine extra Klasse aus der View für jedes Domänenobjekt
Ein anderer Ansatz wäre, für jedes Domänenobjekt noch ein Objekt aus der View zu nutzen.
Das könnte z.B. so aussehen:

PHP-Code:

  class MemberView extends UserView

{

    public function hasLink()

    {

        return true;

    }

    //...

}

 
class GuestView extends UserView

{

    public function hasLink()

    {

        return false;

    }

    //...

}

 
abstract class UserView

{

    public static factory(User $user)

    {

        if ($user instanceOf Member) {

            return new MemberView($user);

        } else {

            return new GuestView($user);

        }

    }

 
    abstract function hasLink();

    abstract function getLink();

    //...

}

Das Positive:

Die if-else- bzw. switch-Konstrukte werden auf ein Minimum reduziert.
Das Model kennt keine Daten der View

Das Negative:

Parallele Vererbungshierarchien
Sehr starke Kopplung der View-Klassen an das Model, Änderungen müssten oft doppelt erfolgen.

Wirklich gefallen tut mir auch diese Möglichkeit nicht. Gibt es für mein Problem ein Möglichkeit, die ich übersehen habe? Irgendeine BestChoice vielleicht?

nikosch · 08.06.2011, 06:14

Sehe ich jetzt nicht dramatisch. Wenn die Modellogik unterschiedlich ist und die Viewlogik unterschiedlich, braucht man halt jeweils mehrere Objekte. Ist die Viewlogik sehr ähnlich, könnte man mehrere Models mit einer gemeinsamen View abfeiern (Templatelogik o.ä.). Aber irgendwo muss die Logik ja stecken.

xm22 · 08.06.2011, 09:57

Ins Model sollte die Darstellungslogik mit Sicherheit nicht.
Ich würde auch nicht für wichtige Threads eine weitere Klasse implementieren. Was ist, wenn es noch andere Thread-Typen gibt? Noch mehr Klassen? Nee - lieber als Attribut.
Definier doch im Template anhand eines Attributs des Threads eine CSS-Klasse. Z. B.

PHP-Code:

 
<div class="thread thread-<?php echo $thread->getType(); ?>">
...
</div>
...

fab · 08.06.2011, 10:22

Zitat:

Zitat von [-UFO-]Melkor

Eine extra Klasse aus der View für jedes Domänenobjekt
Ein anderer Ansatz wäre, für jedes Domänenobjekt noch ein Objekt aus der View zu nutzen.
Das könnte z.B. so aussehen:

PHP-Code:

  class MemberView extends UserView

{

    public function hasLink()

    {

        return true;

    }

    //...

}

 
class GuestView extends UserView

{

    public function hasLink()

    {

        return false;

    }

    //...

}

 
abstract class UserView

{

    public static factory(User $user)

    {

        if ($user instanceOf Member) {

            return new MemberView($user);

        } else {

            return new GuestView($user);

        }

    }

 
    abstract function hasLink();

    abstract function getLink();

    //...

}

Im Prinzip würde ich es diesen Ansatz verfolgen aber so hast du deine if-else Konstrukte nur verlagert. Du fragst jetzt halt hasLink() ab anstatt die Klasse, ist damit wirklich etwas gewonnen?

Wie wäre es damit:

PHP-Code:

   
abstract class UserView

{

    // ...

 
    public static factory(User $user)

    {

        if ($user instanceOf Member) {

            return new MemberView($user);

        } else {

            return new GuestView($user);

        }

    }

 
    abstract function renderName();

}

 
class MemberView extends UserView

{

    public function renderName()

    {

        // Name mit Link

    }

    //...

}

 
class GuestView extends UserView

{

    public function renderName()

    {

        // Name ohne Link

    }

    //...

}

dr.e. · 08.06.2011, 15:38

Zitat:

Entscheidung ins Model verlagern
Eine Möglichkeit wäre es, der Klasse Thread z.B. eine getImageSource-Methode zu verpassen, die dann von dem ImportantThread überschrieben werden könnte. Allerdings ist dies ein Wissen, welches das Model gar nicht haben sollte (je nach View mag es verschiedene Bilder geben). Von daher klingt dieser Ansatz für mich nicht sehr klug.

Warum nicht? MVC einzusetzen bedeutet nicht, sein OOP-Verständnis beiseite legen zu dürfen. Was du hier hast sind keine Models im klassischen Sinn von MVC, sondern Domänen-Objekte. Wenn du so willst, ist dein Model eine DSomänen-Objekt-Sammlung bzw. -Struktur.

Betrachtet man die einzelnen Typen, so ist das Icon/Bild eines solchen Threads definitiv ein Attribut eines Domänen-Objekts und hat nichts in der View-Logik zu suchen. Ein Important-Thread ist also ein ganz einfacher Thread, dessen Bild einfach anders ist. Wer diese Information in den Thread injiziert sei zunächst dahingestellt, kann aber sehr einfach an Hand des Typen ohne jegliches zusätzliche Mapping erfolgen (Icon hat den Typ-Bezeichner im Datei-Namen) oder durch explizites Mapping in einer Business-Schicht an Hand von diversen Informationen initialisiert werden.

Fakt ist jedoch, dass der oben vorgestellte Ansatz definitiv Blödsinn ist, da du Funktions- und Struktur-Duplizierung betreibst.

xm22 · 08.06.2011, 15:58

Zitat:

so ist das Icon/Bild eines solchen Threads definitiv ein Attribut eines Domänen-Objekts

Ein Icon hat in meinen Augen nichts mit der Rolle des Threads in der Applikation zu tun. Das dient lediglich der Darstellung. Da würde ich eher für einen "Typ" plädieren. Diesen kann man dann noch für andere Dinge verwenden. Was wäre denn z. B., wenn dieser Thread-Typ nicht nur ein anderes Bild, sondern auch eine andere Hintergrundfarbe haben soll? Noch ein Attribut?

Was anderes ist das z. B. bei einem User und dessen Avatar-Bild.

dr.e. · 08.06.2011, 16:04

Deswegen hatte ich ja auch

Zitat:

Wer diese Information in den Thread injiziert sei zunächst dahingestellt, kann aber sehr einfach an Hand des Typen ohne jegliches zusätzliche Mapping erfolgen (Icon hat den Typ-Bezeichner im Datei-Namen)

vorgeschlagen, was ich persönlich bevorzugen würde. Beides ist jedoch valide, denn ein Mapping in der Business-Schicht wiederspricht nicht dem Ansatz aus einem Thread einen ImportantThread zu machen, der das Interface einfach um GUI-relevante Attribute ergänzt. Fraglich ist dann allerdings, wie ich in der GUI mit den unterschiedlichen Instanzen umgehe. jedes mal instanceof zu nutzen halte ich für keine gute Idee.

xm22 · 08.06.2011, 16:09

Zitat:

vorgeschlagen, was ich persönlich bevorzugen würde.

So meinte ich das

Ist mir irgendwie entgangen..

EDIT:

Zitat:

jedes mal instanceof zu nutzen halte ich für keine gute Idee.

Dem stimme ich zu - So lange sich ein Important-Thread von einem nur marginal unterscheidet (Anderer Typ), halte ich es für unsinnig, dafür eine eigene Klasse zu implementieren.

nikosch · 08.06.2011, 16:09

Zitat:

PHP-Code:

      public static factory(User $user)
    {
        switch ($user->getType ()) {
          case 'member':
          case 'admin':
            return new MemberView($user);

          case 'supermember':
            return new SuperMemberView($user);

          default:
            return new GuestView($user);
        }
    }

Davon abgesehen würde ich statt Factory method eine echte Factory (als Objekt) benutzen. Das sind dann noch mehr Objekte, aber Du bleibst flexibler für Erweiterungen.

[-UFO-]Melkor · 08.06.2011, 23:09

Ich versuche das mal zusammenzufassen, mal sehen ob ich alles richtig verstanden habe.

Einige Informationen lassen sich direkt im Domänen-Objekt unterbringen (z.B. der Avatar eines Users). Dementsprechend lässt sich auch die Unterscheidung verschiedener Typen bewirken, die sich z.B. nur in ihrer Darstellung unterscheiden.

Will ich komplexere View-Logik ausdrücken, arbeite ich aber lieber mit extra Klassen für die View-Logik.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
MVC Fragen	BlackScorp	Software-Design	42	07.06.2011 19:12
MySQL per View auf eine andere DB zugreifen	jens76	Datenbanken	17	06.06.2011 15:42
Document Object Model	farant	Wiki Diskussionsforum	0	15.04.2011 11:57
[Erledigt] Korrektes Umgehen mit View bei MVC	Trainmaster	Software-Design	7	22.10.2010 12:41
View \| Controller \| .. wohin mit Errors?	d0ne	Off-Topic Diskussionen	13	18.10.2010 17:42
cakePHP View Abstraktion	Deltachaos	Software-Design	6	08.10.2010 15:20
phpdoc view	notyyy	PHP-Fortgeschrittene	7	07.09.2010 20:12
Model view controll	Leberwurstbrot	PHP Tipps 2010	14	05.03.2010 18:14
MVC Model Daten als Referenz oder Kopie übergeben?	serious-cool	PHP Tipps 2009	1	12.01.2010 22:10
Template System -> View in PHP	Floid	PHP-Fortgeschrittene	12	22.11.2009 11:58
Zend_Controller_Router_Route routet nach der View	boolean	PHP-Fortgeschrittene	10	13.08.2009 11:12
View vs. Join	dsmcg	Datenbanken	8	17.03.2009 07:58
Welche Information bekommen die einzelnen MVC-Elemente?	Zergling-new	PHP-Fortgeschrittene	14	06.10.2007 16:59
cms selber machen. tipps / dateistruktur	Promaetheus	PHP Tipps 2007	31	16.03.2007 19:53
PHP und HTML sinnvoll verbinden	Fatal Error	PHP Tipps 2007	10	07.01.2007 15:12

08.06.2011, 01:35
[-UFO-]Melkor Erfahrener Benutzer Registriert seit: 26.05.2008 Beiträge: 200 PHP-Kenntnisse: Fortgeschritten	[Erledigt] Model-View Konzeption Ich stehe im Moment vor dem Problem, wie ich mein Model und meine View miteinander verbinden kann. Ich will versuchen, es an einem einfach gehaltenem Beispiel deutlich zu machen: Das Domain-Model: PHP-Code: `class Member implements User { //... } class Guest implements User { //... } interface User { public function getId(); public function getName(); public function getEmailAddress(); } class Thread { public function getAuthor(); public function getName(); } class ImportantThread extends Thread { }` Der View übergebe ich nun die jeweiligen Objekte. Dort möchte ich nun auf die verschiedenen Arten von Objekten reagieren: Ein ImportantThread soll ein anderes Bild als ein Thread bekommen. Ein Member soll verlinkt werden, ein Guest nicht. Wie komme ich nun darum herum, in meiner View ständig if-else- oder switch-Konstrukte verwenden zu müssen? Ein paar Ansätze habe ich, aber so wirklich gefallen tun sie mir alle nicht. Entscheidung ins Model verlagern Eine Möglichkeit wäre es, der Klasse Thread z.B. eine getImageSource-Methode zu verpassen, die dann von dem ImportantThread überschrieben werden könnte. Allerdings ist dies ein Wissen, welches das Model gar nicht haben sollte (je nach View mag es verschiedene Bilder geben). Von daher klingt dieser Ansatz für mich nicht sehr klug. Eine extra Klasse aus der View für jedes Domänenobjekt Ein anderer Ansatz wäre, für jedes Domänenobjekt noch ein Objekt aus der View zu nutzen. Das könnte z.B. so aussehen: PHP-Code: class MemberView extends UserView { public function hasLink() { return true; } //... } class GuestView extends UserView { public function hasLink() { return false; } //... } abstract class UserView { public static factory(User $user) { if ($user instanceOf Member) { return new MemberView($user); } else { return new GuestView($user); } } abstract function hasLink(); abstract function getLink(); //... } Das Positive: Die if-else- bzw. switch-Konstrukte werden auf ein Minimum reduziert. Das Model kennt keine Daten der View Das Negative: Parallele Vererbungshierarchien Sehr starke Kopplung der View-Klassen an das Model, Änderungen müssten oft doppelt erfolgen. Wirklich gefallen tut mir auch diese Möglichkeit nicht. Gibt es für mein Problem ein Möglichkeit, die ich übersehen habe? Irgendeine BestChoice vielleicht? __________________ Programming PHP


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

08.06.2011, 06:14
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Sehe ich jetzt nicht dramatisch. Wenn die Modellogik unterschiedlich ist und die Viewlogik unterschiedlich, braucht man halt jeweils mehrere Objekte. Ist die Viewlogik sehr ähnlich, könnte man mehrere Models mit einer gemeinsamen View abfeiern (Templatelogik o.ä.). Aber irgendwo muss die Logik ja stecken. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

08.06.2011, 09:57
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.169 PHP-Kenntnisse: Fortgeschritten	Ins Model sollte die Darstellungslogik mit Sicherheit nicht. Ich würde auch nicht für wichtige Threads eine weitere Klasse implementieren. Was ist, wenn es noch andere Thread-Typen gibt? Noch mehr Klassen? Nee - lieber als Attribut. Definier doch im Template anhand eines Attributs des Threads eine CSS-Klasse. Z. B. PHP-Code: `<div class="thread thread-<?php echo $thread->getType(); ?>"> ... </div> ...`

08.06.2011, 23:09
[-UFO-]Melkor Erfahrener Benutzer Registriert seit: 26.05.2008 Beiträge: 200 PHP-Kenntnisse: Fortgeschritten	Ich versuche das mal zusammenzufassen, mal sehen ob ich alles richtig verstanden habe. Einige Informationen lassen sich direkt im Domänen-Objekt unterbringen (z.B. der Avatar eines Users). Dementsprechend lässt sich auch die Unterscheidung verschiedener Typen bewirken, die sich z.B. nur in ihrer Darstellung unterscheiden. Will ich komplexere View-Logik ausdrücken, arbeite ich aber lieber mit extra Klassen für die View-Logik. __________________ Programming PHP