Daten bearbeiten, welche sich in abgeleiteter Klasse befinden

Dravere

CSL schrieb:

Wie wäre es mit einer Id im Interface?

Das verstehe ich unter Typinformationen mit Up-Cast. Jeder Filter hat seine Id oder Typinformation und über die kann man den korrekten Up-Cast machen. Oder meinst du was anderes?

witte schrieb:

Ich verstehe nicht was der Visitor mit der Aufgebenstellung zu tun hat dass der User Filterelemente nachträglich bearbeiten will?

Mit einem Visitor kommst du wieder an die abgeleiteten Klassen heran und kannst somit diese bearbeiten. Auf das obige Beispiel angewandt:

public interface IFilter
{
  bool Check(String arg);
  void ApplyVisitor(IFilterVisitor visitor);
}

public interface IFilterVisitor
{
  void Set(StartsWithFilter filter);
  void Set(LengthFilter filter);
  // usw.
}

public class LengthFilter
  : IFilter
{
  // ... siehe oben ...

  public void ApplyVisitor(IFilterVisitor visitor)
  {
    visitor.Set(this);
  }
}

// usw.

Das GUI kann nun auf den zu bearbeitenden Filter so ein Visitor anwenden. In den Set-Methoden werden dann die richtigen GUI-Komponenten für die Bearbeitung des Filters erstellt/geholt/aufgerufen und zusätzlich hat man auch das richtige Objekt, von welchem man die Daten holen, bzw. setzen, kann.

witte schrieb:

Kann man nicht den Filtern einen Namen geben, der auch von den Objekten selbst generiert werden kann "Suchtext beginnt mit 'Arg'" und dann die gewählten Filter in einem Dictionary speichern mit Namen als Key? Dann kann der User über diesen namen einzelne Elemente ansprechen.

Verstehe deinen Vorschlag nicht ganz. Es geht darum, dass in einer List<IFilter> der Filter an der Stelle x geholt werden soll, überprüft werden soll, was für ein Filter das ist, zum Beispiel ein LengthFilter und dann dessen Attribute verändert werden können, also zum Beispiel Length verändern.

Grüssli

witte

Dravere schrieb:

Verstehe deinen Vorschlag nicht ganz. Es geht darum, dass in einer List<IFilter> der Filter an der Stelle x geholt werden soll, überprüft werden soll, was für ein Filter das ist, zum Beispiel ein LengthFilter und dann dessen Attribute verändert werden können, also zum Beispiel Length verändern.

Du gehst also davon aus dass die Filter disjunkt sind, dass es für jeden Typ maximal eine Filterung geben kann. Das war mir nicht klar.

Text contains 'jupiter' or Text contains 'saturn'

witte

Wenn die Filteranzahl nicht zu groß ist und sowieso für jeden Filtertyp maximal einen geben kann, könnte man diese Filter doch auch in ein Objekt zusammenfassen welches die verschiedenen Filter als Member enthält.

class Filterset
{
  public StartsWithFilter StartsWithFilter  { get; set; }
  public LengthFilter LengthFilter { get; set; }
  ...
}

beselbube

witte schrieb:

Wenn die Filteranzahl nicht zu groß ist und sowieso für jeden Filtertyp maximal einen geben kann, könnte man diese Filter doch auch in ein Objekt zusammenfassen welches die verschiedenen Filter als Member enthält.
class Filterset
{
  public StartsWithFilter StartsWithFilter  { get; set; }
  public LengthFilter LengthFilter { get; set; }
  ...
}

ist das nicht vom prinzip her das gleiche wie der visitor?

Dravere

witte schrieb:

Wenn die Filteranzahl nicht zu groß ist und sowieso für jeden Filtertyp maximal einen geben kann, könnte man diese Filter doch auch in ein Objekt zusammenfassen welches die verschiedenen Filter als Member enthält.

Das ist die Super-God-Filter Klasse
Oder zumindest sowas ähnliches.

witte schrieb:

Du gehst also davon aus dass die Filter disjunkt sind, dass es für jeden Typ maximal eine Filterung geben kann. Das war mir nicht klar.

Was du darunter nun verstehst, ist mir wieder nicht klar *sich langsam blöd vorkommt*
Es kann schon mehrere LengthFilter und mehrere StartsWithFilter haben. Es können aber auch noch andere Filter vorkommen. Die können gleich aufgebaut und verschieden sein. Die können die gleichen Attribute haben und verschiedene. Die einzige Gemeinsamkeit die besteht, ist das Interface IFilter .

Grüssli

Th69

Hallo Dravere,

so ganz verstehe ich dein Problem nicht. Wenn du eine List<IFilter> hast, so sind ja trotzdem dadrin die einzelnen konkreten Objekte der verschiedenen Filterklassen gespeichert, d.h. mittels einer 'is' bzw. 'as' Abfrage kommst du dann an die einzelnen Filter wieder dran (das meinst du mit "Testen und Up-Cast"?). Sicherlich benötigst du dann eine Methode dafür, welche alle Filterklassen der Reihe nach durchgeht.

Du mußt ja dann dem Benutzer sowieso individuelle GUI-Masken zur Änderung anzeigen. Als Ausweg bliebe sonst nur eine allgemeine Methode über Reflection (d.h. je nach Eigenschaft der Filterklasse wird ein bestimmtes Control angezeigt, z.B. string -> TextBox, int -> NumericUpDown, bool -> CheckBox etc.)
Oder als Alternative das PropertyGrid?

~(Irgendeinen Tod mußt du sterben...)~

Dravere

Th69 schrieb:

so ganz verstehe ich dein Problem nicht. Wenn du eine List<IFilter> hast, so sind ja trotzdem dadrin die einzelnen konkreten Objekte der verschiedenen Filterklassen gespeichert, d.h. mittels einer 'is' bzw. 'as' Abfrage kommst du dann an die einzelnen Filter wieder dran (das meinst du mit "Testen und Up-Cast"?). Sicherlich benötigst du dann eine Methode dafür, welche alle Filterklassen der Reihe nach durchgeht.

Verstanden hast du das Problem doch absolut korrekt. Mein Problem ist, dass mir dieser Up-Cast nicht gefällt und ich gerne eine Methode finden würde, wo dies nicht nötig ist.
Statt mit is oder as zu testen, verwende ich allerdings lieber die Id Möglichkeit, bzw. meistens verwende ich eine Guid , damit ich den Filtertyp über die Programmgrenze hinaus eindeutig identifizieren kann.

Th69 schrieb:

~(Irgendeinen Tod mußt du sterben...)~

Ich will aber schön sterben :p
Es ist ja nicht so, dass ich keine Lösung für das Problem habe. Ich suche aktuell nur nach akademisch schöneren Lösungen, als ich bisher gefunden habe

Grüssli

mogel

Dravere schrieb:

Th69 schrieb:

so ganz verstehe ich dein Problem nicht. Wenn du eine List<IFilter> hast, so sind ja trotzdem dadrin die einzelnen konkreten Objekte der verschiedenen Filterklassen gespeichert, d.h. mittels einer 'is' bzw. 'as' Abfrage kommst du dann an die einzelnen Filter wieder dran (das meinst du mit "Testen und Up-Cast"?). Sicherlich benötigst du dann eine Methode dafür, welche alle Filterklassen der Reihe nach durchgeht.

Verstanden hast du das Problem doch absolut korrekt. Mein Problem ist, dass mir dieser Up-Cast nicht gefällt und ich gerne eine Methode finden würde, wo dies nicht nötig ist.
Statt mit is oder as zu testen, verwende ich allerdings lieber die Id Möglichkeit, bzw. meistens verwende ich eine Guid , damit ich den Filtertyp über die Programmgrenze hinaus eindeutig identifizieren kann.

??

public interface IFilter
{
  bool Check(String arg);
  Control GetConfigControl(); // <-- ??
}

hand, mogel

Dravere

@mogel,
Schon mal etwas von Trennung von Daten, GUI und Logik gehört? Eine GUI-Komponente hat definitiv nichts in IFilter zu suchen.
Was für ein Control soll da zurückgegeben werden? WinForms? WPF? Oder was eigenes? Vielleicht ein Konsolen-Control?

Grüssli

mogel

Dravere schrieb:

Schon mal etwas von Trennung von Daten, GUI und Logik gehört? Eine GUI-Komponente hat definitiv nichts in IFilter zu suchen.
Was für ein Control soll da zurückgegeben werden? WinForms? WPF? Oder was eigenes? Vielleicht ein Konsolen-Control?

wenn Du mir jetzt verräts wo ich das MVC zerstört habe ... ein Interface gehört bei mir zum Controler, welcher zwischen Model (Filterimplementierung) und View (Control) vermittelt

Dravere

mogel schrieb:

Dravere schrieb:

Schon mal etwas von Trennung von Daten, GUI und Logik gehört? Eine GUI-Komponente hat definitiv nichts in IFilter zu suchen.
Was für ein Control soll da zurückgegeben werden? WinForms? WPF? Oder was eigenes? Vielleicht ein Konsolen-Control?

wenn Du mir jetzt verräts wo ich das MVC zerstört habe ... ein Interface gehört bei mir zum Controler, welcher zwischen Model (Filterimplementierung) und View (Control) vermittelt

Was ist das denn für eine Ansicht von MVC? Damit bringt dir MVC ja rein gar nichts, weil du immer noch alles fest verkoppelt hast. Du kannst nicht einfach deine View austauschen und zum Beispiel von WinForms auf WPF wechseln, weil du die Filter (also Daten) fix mit der View verkoppelt hast. Und das sogar noch über die stärkste Verbindung überhaupt: Vererbung.

Grüssli

mogel

lassen wir mal WPF weg - nutze ich nicht

IFilter filter = something as IFilter;
Control control = filter->GetConfigControl();

ich sehe da nur eine Bindung - und zwar zwischen einem konkreten Filter und seiner konkrekten GUI für die Einstellungen

Dravere

mogel schrieb:

ich sehe da nur eine Bindung - und zwar zwischen einem konkreten Filter und seiner konkrekten GUI für die Einstellungen

Genau, es ist eine Bindung, nämlich zwischen WinForms und IFilter . Was ist aber nun, wenn jemand IFilter nicht in WinForms anzeigen möchte, sondern in WPF? Oder vielleicht auf der Konsole eine Ausgabe machen möchte. Dann bist du völlig auf WinForms fixiert. Du hast die View eben nicht von den Daten getrennt, sondern völlig zusammengeschweisst. Das ist nicht der Sinn von MVC.

Mit korrekten MVC kannst du IFilter dann ohne Probleme auch in WPF verwenden oder nur in einem Konsolenprogramm. Dann hast du eine View für WinForms, du hast eine View für WPF, du hast eine View für die Konsole, usw. usf.

Grüssli

mogel

Was ist aber nun, wenn jemand IFilter nicht in WinForms anzeigen möchte, sondern in WPF?

wie schon geschrieben - ich nutze WPF nicht und wolltes erstmal weg lassen ... es ging um grundsätzliche MVC Dinge

public interface IFilter
{
  bool Check(String arg);
  IFilterConfig GetConfigControl();
}

public interface IFilterConfig
{
  bool OpenFilterConfig();
}

public class FormsFilterConfig : IFilterConfig
{
}

public class WPFFilterConfig : IFilterConfig
{
}

public class ConsoleFilterConfig : IFilterConfig
{
}

Du musst irgendwo eine Bindung zwischen IFilter und der Konfiguration herstellen ... kannst Du auch in einer statischen Methode machen (was etwas mehr Pflege erfordert) - ist aber prinzipell egal ... es existiert dann aber immer eine feste Bindung zwischen einem konkreten Filter und einer konkreten Oberfläche

selbst wenn wir nur bei Forms bleiben

public interface IFilter
{
  bool Check(String arg);
  Control GetConfigControl();
}

hier wird noch nicht mal ein Control instanziert welches sinnlos Speicher verschwendet ... nutzen kannst Du den Filter dennoch beliebig ... selbst die Darstellung der Config ist unabhängig vom Filter ... alternativ kannst Du das Ganze auch trennen

public interface IFilterConfig
{
  Control GetConfigControl();
}

public class MyFiler : IFilter, IFilterConfig
{
}

egal wie Du es drehst und wendest ... über das C verbindest Du M & V

Dravere

mogel schrieb:

wie schon geschrieben - ich nutze WPF nicht und wolltes erstmal weg lassen ... es ging um grundsätzliche MVC Dinge

Wenn du mal meinen Beitrag genau liest, rede ich auch über allgemeine MVC Dinge. Ob WPF, WinForms, Konsole oder sonstwas ist völlig egal, das sind nur Beispiele.

mogel schrieb:

Du musst irgendwo eine Bindung zwischen IFilter und der Konfiguration herstellen ... kannst Du auch in einer statischen Methode machen (was etwas mehr Pflege erfordert) - ist aber prinzipell egal ... es existiert dann aber immer eine feste Bindung zwischen einem konkreten Filter und einer konkreten Oberfläche

Ja, aber die sollte die Filterklasse nicht beeinflussen. Du bindest alles mit Superkleber zusammen, statt es nur über Schnittstellen laufen zu lassen. IFilter sollte das Model sein und nichts über das View oder den Controller wissen.

Also mal etwas mit Pseudo-Code verdeutlicht:

public interface IFilterView
{
  void Display(IFilter filter);
}

public class FilterWPFView : IFilterView { /* ... */ }

public class FilterWinFormsView : IFilterView { /* ... */ }

public class FilterConsoleView : IFilterView { /* ... */ }

// ...

IFilterView view = new FilterWPFView();
view.Display(filter);

IFilter hat somit keine Abhängigkeit zur View mehr. Ich kann IFilter in eine eigene DLL auslagern, welche keine Abhängigkeiten zur WPF oder WinForms DLL hat. Hier hast du eine deutlich stärkere Trennung von Daten und Ansicht.

Vererbung ist immer die stärkste Verbindung, welche es gibt. Im allgemeinen sollte sie als letztes in Betracht gezogen werden.

mogel schrieb:

egal wie Du es drehst und wendest ... über das C verbindest Du M & V

Wie ich schon mehrfach gesagt habe, geht es darum, wie man es verbindet. MVC war ja dazugedacht, dass man die Dinger eben stark entkoppelt. Da ist es nicht sehr sinnvoll, dies mit der stärksten Bindung, welche es gibt, wieder zusammenzukleben.

Grüssli

mogel

IFilter sollte das Model sein und nichts über das View oder den Controller wissen.

ich betrachte Interfaces als Bestandteil von C ... wärend Klassen zu M gehören ... wir haben hier also schon zwei Ansichten

IFilterView view = new FilterWPFView();
view.Display(filter);

wenn ich jetzt einen eigenen Filter implementiere, zeigt mir Dein FilterWPFView Details meiner Klasse an?

asc

mogel schrieb:

ich betrachte Interfaces als Bestandteil von C ... wärend Klassen zu M gehören ... wir haben hier also schon zwei Ansichten

Das hat wenig mit Ansichen zu tun, das was du betreibst widerspricht den Grundprinzipien von MVC, und sollte daher korrekterweise auch nicht so genannt werden.

Dravere

mogel schrieb:

ich betrachte Interfaces als Bestandteil von C ... wärend Klassen zu M gehören ... wir haben hier also schon zwei Ansichten

Siehe Antwort von asc. Ich würde dir empfehlen, dich mit dieser Thematik nochmals auseinander zu setzen.

mogel schrieb:

IFilterView view = new FilterWPFView();
view.Display(filter);
wenn ich jetzt einen eigenen Filter implementiere, zeigt mir Dein FilterWPFView Details meiner Klasse an?

Sofern sich dein Filter an die definierten Konventionen hält, sicher. Aber wer würde dir verbieten, ein eigenes View für deinen Filter zu schreiben, welches von IFilterView ableitet? Danach kannst du einfach diese View für deinen Filter verwenden.

Ich persönlich erkläre es noch gerne an diesem Beispiel:

public class ShapeData
{
  public int X { get; set; }
  public int Y { get; set; }
  public int Width { get; set; }
  public int Height { get; set; }
}

public interface IShapeView
{
  void Display(ShapeData data);
}

public class Shape
{
  public ShapeData Data { get; set; }
  public IShapeView View { get; set; }

  public void Display()
  {
    if(this.Data != null && this.View != null)
    {
      this.View.Display(this.Data);
    }
  }
}

Perfekt, sollte alles klar sein oder? Nun wollen wir eine Ellipse darstellen?

public class EllipseView
  : IShapeView
{
  public void Display(ShapeData data)
  {
    // Das Ding zeichnen oder auf der Konsole ausgeben oder was auch immer.
  }
}

// ...

Shape shape = new Shape();
shape.Data = new ShapeData();
// Werte zuweisen ...
shape.View = new EllipseView();

shape.Display();

Gut ... jetzt hätte ich aber gerne dieses Rechteck auch als Begrenzung um die Ellipse angezeigt. Kein Problem!

public class RectView
  : IShapeView
{
  public void Display(ShapeData data)
  {
    // Einfach DrawRect(data.X, data.Y, data.Width, data.Height) oder sowas ...
  }
}

// ...
// Wir können die Variable shape von vorhin gleich wiederverwenden.
// Die Daten werden belassen, wir verändern nur die View.
shape.View = new RectView();
shape.Display();

Was will man mehr?
Das kann man nun um beliebige Views erweitern, welche in das einfache Schema mit dem Rechteck passt. Man kann sogar theoretisch Kreis-Views machen, obwohl dies gar nicht nötig ist, da man dies von den Daten her erzwingen könnte mit einer EllipseView. Da wäre zum Beispiel eine BigCircleView und eine SmallCircleView möglich, welche jeweils entweder den grössten oder kleinsten Wert für den Radius von der Länge und Breite heranziehen. Gleiches kann man dann auch für das Quadrat machen, obwohl man es bereits mit RectView und korrekten Daten erreichen kann. Für die korrekten ShapeDaten könnte man sogar entsprechende statische Funktionen anbieten:

public static ShapeData CreateCircle(int centerX, int centerY, int radius)
{
  // ...
}

public static ShapeData CreateSquare(int x, int y, int length)
{
  // ...
}

Das ist meiner Meinung nach sehr schönes MVC. So sollte die Objektorientierung erklärt werden und nicht irgendwie probieren einen Kreis von einer Ellipse abzuleiten oder umgekehrt und solchen Unsinn

Problematisch wird es eben erst, wenn die Daten auch ein polymorphes Objekt darstellen und man nicht an alle Daten herankommt, an welche man herankommen möchte. Dann wird es grundsätzlich knifflig, aber nicht unmöglich. Man kann zum Beispiel für jeden Filter-Typ eine View im Controller registrieren. Der Controller sucht dann für den Datentyp gleich das richtige View aus. Im View muss dann eben ein Up-Cast durchgeführt werden.

Ich habe jetzt nicht die vollständige .Net Bibliothek im Kopf und bin zu faul nachzuschauen, aber so ganz grob, würde dies wohl so aussehen:

public class FilterDisplayController
{
  private SortedDictionary<Guid, IFilterView> m_views;

  public void RegisterView<T>(IFilterView view)
    where T : IFilter
  {
    Guid guid = typeof(T).GUID;
    m_views[guid] = view;
  }

  public void Display(IFilter filter)
  {
    Guid guid = filter.GetType().GUID;

    IFilterView view;
    if(m_view.TryGetValue(guid, out view))
    {
      view.Display(filter);
    }
  }
}

Vielleicht könnte man die View-Zuordnung auch statisch setzen ...

Naja, aber sollte auch nur ein Erläuterungsbeispiel sein, muss ja jetzt nicht gleich perfekt sein. Zudem ist es nun 2 Uhr und ich wollte um 23:30 Uhr ins Nest, damit ich morgen/heute mich noch weiter in Lua einarbeiten kann.

Herr Dravere, lernen sie endlich rechtzeitig in ihr Nest zu verschwinden!

Grüssli

mogel

Dravere schrieb:

mogel schrieb:

ich betrachte Interfaces als Bestandteil von C ... wärend Klassen zu M gehören ... wir haben hier also schon zwei Ansichten

Siehe Antwort von asc. Ich würde dir empfehlen, dich mit dieser Thematik nochmals auseinander zu setzen.

was genau zum M / zum V / zum C gehört ist reine Interpretationssache ... beim MVC geht es darum die Funktionalität von der Ansicht zu trennen

Sofern sich dein Filter an die definierten Konventionen hält, sicher.

irgendwie hängst Du damit das Model fest an den View

Aber wer würde dir verbieten, ein eigenes View für deinen Filter zu schreiben, welches von IFilterView ableitet?

das kann von was auch immer ableiten - z.B. Control

Ich persönlich erkläre es noch gerne an diesem Beispiel:
[...Kapselung von View & Model in einer Klasse..]

Im View muss dann eben ein Up-Cast durchgeführt werden.

Vielleicht könnte man die View-Zuordnung auch statisch setzen ...

ah - und was habe ich gemacht ... ich habe das View statisch an das Model gehangen

der Fehler ist evt. das ich da direkt gleich ein Control gemacht habe und somit die Möglichkeiten festgelegt habe ... da sollte wohl wirklich eher ein IFilterView hin ... allerdings würde ich dennoch beibehalten das der Filter seinen View selber liefert ... wenn da noch eine entsprechende Methode hinkommt um den IFilterView entsprechend bei der Erzeugung des Filters zu setzen, ist dem Filter sein View völlig egal ... außerdem sparst Du Dir das wilde Casten und/oder Suchen nach dem richtigen View zum Model

hand, mogel

Dravere

mogel schrieb:

Dravere schrieb:

mogel schrieb:

ich betrachte Interfaces als Bestandteil von C ... wärend Klassen zu M gehören ... wir haben hier also schon zwei Ansichten

Siehe Antwort von asc. Ich würde dir empfehlen, dich mit dieser Thematik nochmals auseinander zu setzen.

was genau zum M / zum V / zum C gehört ist reine Interpretationssache ... beim MVC geht es darum die Funktionalität von der Ansicht zu trennen

Lies doch bitte mal die Stelle genau, welche dort steht. Danach schlägst du bitte die Begriffe Architektur- und Entwurfsmuster nach. Ob man es nun als Architektur- oder Entwurfsmuster betrachtet, macht keinen unterschied darin, was zu M, was zu V und was zum C gehört, das ist bei beiden gleich.

Es geht eigentlich eher darum, auf welcher Ebene man MVC anwendet. Wenn man es als Architekturmuster sieht, dann wendet man MVC an, um die Softwareachritektur aufzubauen. Also quasi in einem übergeordneten Grundgedanke. Das kann man durch die Verwendung von Schichten (Layers) erreichen. Ist vor allem im Bereich von Enterprise-Software gang und gäbe.
Wenn man es als Entwurfsmuster sieht, dann verwendet man es direkt im Code, um einzelne Bereiche umzusetzen. Wie es hier gerade besprochen wurde.

mogel schrieb:

Sofern sich dein Filter an die definierten Konventionen hält, sicher.

irgendwie hängst Du damit das Model fest an den View

Klar hat man eine gewisse Bindung, dass hat ja noch nie jemand abgestreitet. Die Frage ist nur und ich glaube, dass ich mich mindestens zum dritten Mal wiederhole, wie stark man diese Bindung macht. Meine Bindung ist extrem lose und funktioniert durch Funktionsparameter. Man kann alles jederzeit austauschen. Man kann auch andere Views an das Model fest anbinden. Schliesslich ist MVC keine 1:1:1 Beziehung, sondern eine mc Beziehung.

mogel schrieb:

Aber wer würde dir verbieten, ein eigenes View für deinen Filter zu schreiben, welches von IFilterView ableitet?

das kann von was auch immer ableiten - z.B. Control

Klar kann man es von was auch immer ableiten. Darum ging es hier ja nicht. In diesem Fall war einfach die Basis für alle View IFilterView, sofern es über diesen Controller geht. Du kannst aber einen neuen Controller schreiben, welcher mit IFilter umgehen kann und auch andere Arten von Views verwaltet. Das ist ja der Trick von MVC. Man ist äusserst flexibel und kann überall alle Komponenten beliebig austauschen. Das geht bei dir nicht, weil du das View zum fixen Bestandteil der Daten gemacht hast, bzw. direkt zum Bestandteil der Schnittstelle der Daten!

mogel schrieb:

Ich persönlich erkläre es noch gerne an diesem Beispiel:
[...Kapselung von View & Model in einer Klasse..]

Im View muss dann eben ein Up-Cast durchgeführt werden.

Vielleicht könnte man die View-Zuordnung auch statisch setzen ...

ah - und was habe ich gemacht ... ich habe das View statisch an das Model gehangen

Ich meinte, dass man die Variable m_views als statische Variable nehmen könnte. Dann ist die View nicht statisch an das Model fixiert. Man hat immer noch die freie Möglichkeit das ganze anders zuzuordnen.

mogel schrieb:

der Fehler ist evt. das ich da direkt gleich ein Control gemacht habe und somit die Möglichkeiten festgelegt habe ... da sollte wohl wirklich eher ein IFilterView hin ... allerdings würde ich dennoch beibehalten das der Filter seinen View selber liefert ... wenn da noch eine entsprechende Methode hinkommt um den IFilterView entsprechend bei der Erzeugung des Filters zu setzen, ist dem Filter sein View völlig egal ... außerdem sparst Du Dir das wilde Casten und/oder Suchen nach dem richtigen View zum Model

Damit sagst du aus, dass das Model dem Controller das View liefern soll. Lies in jeder beliebigen Quelle zu MVC nach, du wirst überall lesen können, dass du mit dieser Aussage auf dem absoluten Holzweg bist. Denn damit machst du das View zum Bestandteil der Schnittstelle des Model. Aber genau das will man schliesslich verhindern. Man will die Schnittstellen unabhängig gestalten, damit man jede Komponente nach belieben austauschen kann.

Grüssli