Autor Beitrag
Nally
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 46



BeitragVerfasst: Mi 26.11.08 23:53 
Hallo,

mich würde interessieren, warum implement eine

CustomerView (View)

ein

ICustomerView (Interface)

mit Methodenstubs die dann in der CustomerView class implementiert werden?

Was bringt das?

Ich schreibe Code in die View der da doch nicht rein sollte? Nicht nur das, viel schlimmer empfinde ich, was wenn die View ausgetauscht wird, dann sind die definierten Methoden alle ebenso weg???

Edit: ob dus glaubst oder nicht ich habs gerade freiwillig verbessert, denn ja der 1. Satz war gräulich schlecht und falsch formuliert ;-)


Zuletzt bearbeitet von Nally am Do 27.11.08 10:38, insgesamt 2-mal bearbeitet
JüTho
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2021
Erhaltene Danke: 6

Win XP Prof
C# 2.0 (#D für NET 2.0, dazu Firebird); früher Delphi 5 und Delphi 2005 Pro
BeitragVerfasst: Do 27.11.08 10:33 
Hallo,

würdest Du bitte Deinen Beitrag nochmal neu formulieren? Stell Dir bitte vor, dass ihn jemand lesen und verstehen soll, der Deine Gedanken nicht kennt. Vor allem Dein erster Satz könnte erheblich besser verstanden werden, wenn die Grundregeln von Grammatik, Rechtschreibung und Zeichensetzung beachtet würden.

Ich weiß, dass diese "Forderung" oft auf Unverständnis stößt. Aber Dein Satz ist so unverständlich, dass ich doch darum bitten muss.

Danke, ich glaube es Dir. In der ersten Zeile meinst Du vermutlich "implementiert". Wenn ich mir noch zwei Kommata hinzudenke und Wikipedia: Stub nachschlage, verstehe ich auch Deine Frage.

Als Antwort fällt mir aber nur ein, dass das ein Wesen eines Interface ist: Es ist nur ein "Vertrag" darüber, welche Eigenschaften und Methoden definiert sein müssen, aber nicht, wie diese zu realisieren sind. Bei einer anderen Deklaration (also z.B. ein Austausch des Parameters View) muss es auch eine andere Realisierung geben. Vielleicht willst Du eher in Richtung "Vererbung" denken?

Oder habe ich Dein Problem noch nicht verstanden?

Jürgen
Nally Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 46



BeitragVerfasst: Do 27.11.08 11:28 
user profile iconJüTho hat folgendes geschrieben Zum zitierten Posting springen:

Bei einer anderen Deklaration (also z.B. ein Austausch des Parameters View) muss es auch eine andere Realisierung geben. Vielleicht willst Du eher in Richtung "Vererbung" denken?

Oder habe ich Dein Problem noch nicht verstanden?

Jürgen
Hm...

zitat:"...Die Ansicht enthält keinerlei steuernde Logik und ist nur allein für die Darstellung und die Ein- und Ausgaben zuständig. Sie erhält weder Zugriff auf die Funktionalität des Präsentators noch auf das Modell. Sämtliche Steuerung der Ansicht erfolgt vom Präsentator. ..."

Nun gehen wir davon aus ich habe eine View.cs und eine Controller.cs. In der View.cs instaziiere ich im Konstruktor die Controller.cs via

ausblenden C#-Quelltext
1:
 myController = new Controller();					


dann hole ich mir aus der View die Daten z.B. welches Item z.B. Person in meiner ListBox zum löschen selektiert ist und übergebe diese Person der Controller Methode via

ausblenden C#-Quelltext
1:
2:
Person MyPerson = (Person)MyListbox.GetDataBoundItem oder so ähnlich...
myController.DeletePerson(MyPerson);


die Methode ist in der Controller.cs deklariert.

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
private void DeletePerson(Person p)
{
   using (Entities context = new Entities())
   {    

    context.DeleteObject(p);
    context.SaveChanges();
   }

}


Nun wieder zu dem Zitat am Anfang. Meine View kennt den Controller und steuert ja das Verhalten des Programms in dem die Controller.cs instanziiert wird etc...

Wie muss ich da anders vorgehen, damit das ganze mehr MVP-like ist?
Th69
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Moderator
Beiträge: 4799
Erhaltene Danke: 1059

Win10
C#, C++ (VS 2017/19/22)
BeitragVerfasst: Do 27.11.08 13:23 
Nur kurz zur Begriffserklärung: MVP steht für Model-View-Presenter im Gegensatz zu MVC (Model-View-Controller).

Da du von Controller sprichst, bin ich mir nicht sicher welches Pattern du jetzt meinst? (wobei gesagt werden muß, daß es verschiedene Varianten beider Patterns gibt, daher ist die Trennung generell schwierig).

Du solltest aber die Hierarachie umdrehen, d.h. dein Controller (Presenter) sollte die Views sowie die Daten (Model) kennen und mittels Event-Handling werden Änderungen an den Daten dann über den Controller (Presenter) an die entsrpechenden Views weitergegeben.
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Do 27.11.08 13:56 
user profile iconTh69 hat folgendes geschrieben Zum zitierten Posting springen:

Du solltest aber die Hierarachie umdrehen, d.h. dein Controller (Presenter) sollte die Views sowie die Daten (Model) kennen und mittels Event-Handling werden Änderungen an den Daten dann über den Controller (Presenter) an die entsrpechenden Views weitergegeben.


Nur um hier Nallys frage nach Interfaces unterzubringen. Der Presenter sollte nur das Interface des Views kennen, nicht den View selber. Dadurch erhälst du dich Möglichkeit den View auszutauschen(ein Winforms Version, eine WPF Version etc.) bzw. diesen durch einen Mock zu ersetzen um den Presenter isoliert testen zu können.
Nally Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 46



BeitragVerfasst: Do 27.11.08 14:06 
user profile iconTh69 hat folgendes geschrieben Zum zitierten Posting springen:
Nur kurz zur Begriffserklärung: MVP steht für Model-View-Presenter im Gegensatz zu MVC (Model-View-Controller).

Da du von Controller sprichst, bin ich mir nicht sicher welches Pattern du jetzt meinst? (wobei gesagt werden muß, daß es verschiedene Varianten beider Patterns gibt, daher ist die Trennung generell schwierig).

Du solltest aber die Hierarachie umdrehen, d.h. dein Controller (Presenter) sollte die Views sowie die Daten (Model) kennen und mittels Event-Handling werden Änderungen an den Daten dann über den Controller (Presenter) an die entsrpechenden Views weitergegeben.


1.) Ja ich benutze immer Controller weiß aber das es Presenter heißt ;-)

1.5) Das mit dem eventhandling mache ich immer zwischen 2 Forms um die Daten auszutauschen

2.) d.h. also wenn der Presenter die View kennen muss, dann übergebe ich das Form object mit this an den Presenter? Hm damit würden sie sich ja gegenseitig kennen lernen...

aufgerufen in der Form.cs:

new Presenter(this);

so und obige Frage ist überflüssig da:

zitat:"... Der Presenter sollte nur das Interface des Views kennen, nicht den View selber. Dadurch erhälst du dich Möglichkeit den View auszutauschen(ein Winforms Version, eine WPF Version etc.) bzw. diesen durch einen Mock zu ersetzen um den Presenter isoliert testen zu können..."

also wenn der Presenter nur das Interface kennen darf und ich das interface übergebe -wie immer das geschieht/dachte man kann nur objekte übergeben...- warum wird für die View den ein Interface definiert? Warum benötigt die Form.cs ein Interface? Was steht in diesen Methoden.

Ich glaube ich muss meine Threadfrage redefinieren ^^

Habe auf Wiki das MVP durchgelesen bin aber nicht viel schlauer. Hat jemand hier ein sehr sehr kleines Übersichtliches Beispiel in Bezug auf MVP für mich oder noch besser ich versuche mit etwas mehr klarem Wissen das selbst zu implementieren und Ihr verbessert :)

also wäre dies richtig so?

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
   public partial class CustomerView : Window, ICustomerView
    {   
        private ICustomerPresenter presenter;
     
        public CustomerView()
        {
            InitializeComponent();
            
            presenter = new CustomerPresenter(this);
        }


Warum wird hier an den Presenter Konstruktor die View sprich CustomerView übergeben? und nicht ICustomerView also das Interface wie Ihr es fordert?
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Do 27.11.08 14:36 
ausblenden C#-Quelltext
1:
Warum wird hier an den Presenter Konstruktor die View sprich CustomerView übergeben? und nicht ICustomerView also das Interface wie Ihr es fordert?					


Du übergibst nie ein Interface sondern immmer ein konkretes Objekt das dieses Interface implementiert. Du könntest aber jetzt dem gleichen Presenter einen anderen Typ von View übergeben der eben auch dieses Interface implementiert und der Presenter würde (ohne Änderung) trotzdem funktionieren.
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Do 27.11.08 14:41 
Um dein Beispiel zu vervollständigen der dazugehörige Presenter.
Ich persönlich halte ein Interface für den Presenter eher für unnötig. In einer Anwendung ist es eher wahrscheinlich das ein View getauscht wird als das der Presenter ausgetauscht wird. Ist aber Geschmackssache.

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
   public partial class CustomerPresenter 
   {   
        private ICustomerView view;
     
        public CustomerPresenter(ICustomerView view)
        {           
            this.view = view;
        }
   }
Nally Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 46



BeitragVerfasst: Do 27.11.08 15:13 
user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Um dein Beispiel zu vervollständigen der dazugehörige Presenter.
Ich persönlich halte ein Interface für den Presenter eher für unnötig. In einer Anwendung ist es eher wahrscheinlich das ein View getauscht wird als das der Presenter ausgetauscht wird. Ist aber Geschmackssache.

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
   public partial class CustomerPresenter 
   {   
        private ICustomerView view;
     
        public CustomerPresenter(ICustomerView view)
        {           
            this.view = view;
        }
   }


ok danke das verdau ich mal :) aber jetzt mal "Butter auf Fische..." wer schreibt ein Programm und tauscht seine View aus? Also ich entscheide mich für Windows Forms, da WPF nicht wirklich neues bringt... Welcher Kunde der bereits ein office 2007 blue windows forms look nutzt möchte das ganze als WPF, wenns es nicht ein deut Vorteile bringt? Nicht mal der Look ist besser.

Andere Frage:


Dann gibts da noch Dinge wie prüfen ob man im edit/add View mode ist etc... muss man das machen bei Anwendung von MVP?

Beispiel code aus dem www:

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
public virtual void view_DeleteCustomer()
        {
            switch (view.Mode)
            {
                case ViewMode.EditMode:
                    Customer customer = view.CurrentCustomer;
                    var svc = new NWServiceClient();
                    svc.DeleteCustomer(customer);
                    view.CurrentCustomer = null;
                    break;
                case ViewMode.AddMode:
                    break;
                default:
                    break;
            }
        }
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Do 27.11.08 15:21 
ausblenden C#-Quelltext
1:
ok danke das verdau ich mal :) aber jetzt mal "Butter auf Fische..." wer schreibt ein Programm und tauscht seine View aus? Also ich entscheide mich für Windows Forms, da WPF nicht wirklich neues bringt...					


Denk mal in größeren Zeitmaßstaben. Wenn ich jetzt ein Winformsanwendung im multimillionen Zeilencode Bereich schreibe dann kann ich das für 2-3 Jahre mit einer gewissen Investitionssicherheit noch machen aber darüber hinaus? Vielleicht will man dann Richtung Web oder WPF oder Crossplattform mit einem ganz anderen GUI Framework. In einem halbwegs ordentlich designten MVP Framework ist das mit deutlich reduziertem Aufwand möglich.
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19325
Erhaltene Danke: 1749

W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Do 27.11.08 15:28 
user profile iconNally hat folgendes geschrieben Zum zitierten Posting springen:
ok danke das verdau ich mal :) aber jetzt mal "Butter auf Fische..." wer schreibt ein Programm und tauscht seine View aus? Also ich entscheide mich für Windows Forms, da WPF nicht wirklich neues bringt... Welcher Kunde der bereits ein office 2007 blue windows forms look nutzt möchte das ganze als WPF, wenns es nicht ein deut Vorteile bringt? Nicht mal der Look ist besser.
Du weißt ja nicht, was mit der Oberfläche alles noch in Zukunft geschieht, wer weiß, vielleicht soll die ja später einmal animiert oder anders verschönert werden.

Oder vielleicht willst du unter Windows 7 die Anwendung über die neuen Taskbarmenü-Bedienschaltflächen (kA wie MS die nennt) steuern lassen. All das kannst du dann einfach mit unterschiedlichen Views machen, die dann beim Minimieren ausgetauscht werden, etc.

Grundsätzlich bietet sich so auch die Möglichkeit, dass verschiedene Personen leicht an unterschiedlichen Teilen des Programms arbeiten können. Die Schnittstellen sind ja bekannt nachdem sie festgelegt wurden und die Implementierung kann dann unabhängig voneinander passieren.