MVP: andere Konstruktor Parameter als Ansicht und Modell?

Question

Ich experimentiere mit der Implementierung eines leichten MVP-Framework mit Delphi 2009.

Ansichten sind passiv aber unterstützt Datenbindung (über eine Schnittstelle Eigenschaft).

Ich bin vor ein Dilemma: ich mehrere sehr ähnliche Ansichten/Moderator/Modell Triade haben, das heißt:

Bestellformular und ein Kundenformular = Verhalten und Logik die gleiche, aber die Datenquelle für die Datenbindung ist anders und der Formtitel auch. die Datenquelle ist eine gemeinsame Eigenschaft für alle meine Modelle, so ist es kein Problem, um den Formulartitel zu setzen, bin ich gezwungen, es in meinem Referenten

hart Code in meinem Referenten zu schreiben Alles funktioniert gut, aber ich bin in einem Situation, wo ich mehrere einfache mvp Triaden sehr ähnlich sind. Ich möchte es umgestalten, aber in diesem Fall muss ich einige Parameter an den mvp-Konstruktor übergeben.

Bisher mache ich wie folgt aus:

1. Erstellen Sie die Ansicht
2. Erstellen Sie das Modell
3. den Presenter erstellen und im Konstruktor

In der Tat Modell und Ansicht injizieren Ich stehe vor einer Wahl:

1. Haben einige sehr generische Views/Presenter, benutze sie so, aber injiziere 1 oder 2 Parameter in den Konstruktor
2. Habe einige Views/Presenter superclass und leite alle meine ähnliche view/presenter von ihnen ab und setze einige spezifische Werte in den overriden Methoden.

Können Sie mir einige Tipps/Ratschläge geben?

(sorry, wenn ich nicht ganz klar bin)

Answer 1

Fred,

I 1 & 2 in einer Art und Weise wählen, wird die eine abstrakte Ansichten/Moderatoren ist mit das allgemeine Verhalten enthalten und schafft abstrakte Funktionen, Mögliche spezifische Verhaltensweisen, die von Unterklassen implementiert werden.

zum Beispiel

public abstract class AbstractPresenter{ 
     // subclass will be implemented 
     public abstract void InitView(Model model, View view); 
    } 

und dann könnten Sie sublcasses haben, erstreckt sich OrderFormPresenter und CustomerFormPresneter von AbstractPresenter.

public OrderFormPresenter extends AbstractPresenter{ 
    public void InitView(Model model, View, view){ 
     // do something specific values 
    } 
} 

public CustomerFormPresenter extends AbstractPresenter{ 
    public void InitView(Model model, View, view){ 
     // do something specific values 
    } 
} 

Bitte korrigieren Sie mich, wenn es in die falsche Richtung geht. Ich hoffe es hilft.

Tiger

Answer 2

würde ich eine allgemeine Ansicht/Moderator mit Parametern und Unterklasse nur erstellen, wenn nötig.

Answer 3

Ein anderer Ansatz (und die Art und Weise, wie ich dieses Problem gelöst habe, so dass es sehr gut funktionierte) besteht darin, eine generische "Metadaten" -Schnittstelle in das Modell einzubauen, und die Ansicht (entweder Schnittstellen oder über Klassenvererbung) diese dann zu verwenden generische Schnittstellen in Ihrem Presenter. Ich entschied mich für die Vererbung für mein Modell und die Schnittstellen für meine Ansicht (es war einfacher, eine Schnittstelle auf ein vorhandenes Formular zu schlagen, als die Vererbung von Formularen und Frames auf der ganzen Platte zu erfordern). In meiner Lösung nahm der Konstruktor für den Moderator 3 Parameter, das Modell, die Ansicht und den "MVP-Namen". Ich habe den Namen des MVP verwendet, um Einstellungen zu laden, die für das aktuelle Szenario spezifisch waren.