none
Kapseln von Controls (Button etc.) um Abhängigkeit von Herstellern zu vermeiden

    Frage

  • Hallo zusammen,

    ich würde gerne meine Controls wie Buttons, Labels, TextBoxen etc. derart kapseln, dass die Abhängigkeit vom Hersteller in denjenigen DLLS, welche die Controls nutzen, verschwindet.

    Konkret: Wir benutzen derzeit das Toolset von Infragistics, also ist in jeder Solution der Button zum Beispiel vom Typ "Infragistics.Win.MISC.UltraButton". Jede Solution hat daher auch Verweise auf die DLLs von Infragistics, sonst geht's nicht.

    Ich möchte nun erreichen, dass es exakt eine DLL gibt, welche den Verweis auf Infragistics hat. Diese DLL stellt eigene Controls zur Verfügung, zum Beispiel "KHButton". Alle anderen Solutions verweisen nur auf die eine DLL mit dem "KHButton" und wissen gar nicht, dass es sich hier um einen Infragistics-Button handelt. Es soll sogar möglich sein, dass der "KHButton" später mal von "DEvExpress" o.ä. Toolsets ableitet.

    Wie geht man dies am besten an? So hier geht's schon mal nicht:

    public classb4Button: Infragistics.Win.Misc.UltraButton

    Dieser Code erzeugt zwar in einem Form einen schönen Button, die Solution will jedoch trotz allem einen Verweis auf Infragistics...

    Was also ist hier die beste Strategie?

    Gruß, Karsten Heimer.

    Mittwoch, 24. Juni 2015 12:08

Alle Antworten

  • Hallo Karsten,

    Ich glaube nicht, dass das funktioniert. Schliesslich ist ja der Grund weshalb dass Du Infragistics benützt (nehme ich mal an), dass Du die Funktionalität von Infragistics benützen willst. Da kommst Du um die Assembly Referenz eh nicht rum.

    Einziger gehbarer Weg, meines erachtens, wäre dass du gar keine Bibliothek benützt. D.h. Du nimmst immer oder in der Mehrzahl der Fälle die Standard Controls und erweiterst diese wo nötig selbst. Dann bist Du komplett unabhängig.

    Gruss Manuel


    PS: Please mark as answer if helpful. Thanks!

    Blog: www.manuelmeyer.net

    Dienstag, 1. September 2015 20:46
  • Hallo Karsten,

    Ich glaube nicht, dass das funktioniert. Schliesslich ist ja der Grund weshalb dass Du Infragistics benützt (nehme ich mal an), dass Du die Funktionalität von Infragistics benützen willst. Da kommst Du um die Assembly Referenz eh nicht rum.

    Einziger gehbarer Weg, meines erachtens, wäre dass du gar keine Bibliothek benützt. D.h. Du nimmst immer oder in der Mehrzahl der Fälle die Standard Controls und erweiterst diese wo nötig selbst. Dann bist Du komplett unabhängig.

    Gruss Manuel


    PS: Please mark as answer if helpful. Thanks!

    Blog: www.manuelmeyer.net

    Hallo Manuel,

    ich habe schon gemerkt, dass es problematischer ist, als gedacht. So ganz ohne Infragistics wollen wir nun aber auch nicht arbeiten, dafür haben diese Controls zu viel gute Funktionalität. Im Moment rätseln wir noch, was das beste Design wäre...

    Gruß, Karsten.

    Mittwoch, 2. September 2015 06:53
  • Vieleicht kannst Du ja für die komplexen controls (datagrid, etc) auf infragistics ausweichen und den Rest mit den Standard Controls machen...

    Gruss MM


    PS: Please mark as answer if helpful. Thanks!
    Blog: http://www.manuelmeyer.net

    Mittwoch, 2. September 2015 07:24
  • Vieleicht kannst Du ja für die komplexen controls (datagrid, etc) auf infragistics ausweichen und den Rest mit den Standard Controls machen...

    Gruss MM


    PS: Please mark as answer if helpful. Thanks!
    Blog: http://www.manuelmeyer.net

    Nun, dieses Vorgehen würde nicht viel nützen. Hinter dieser Anfrage steckt ein größeres Problem: Wir sind derzeit nicht in der Lage, unsere Solutions mit einer aktuellen Infragistics-Version zu aktualisieren. Unsere Solutions verweisen teilweise aufeinander (zirkulär und direkt gegenseitig), so dass beim Upgrade der ersten Solution auf eine neue Infragistics-Version der Kompilierungsvorgang abbricht, da die jeweils andere Solution noch Bezüge auf die alte Infragistics-Version hat. Es werden auch direkt Infragistics-Komponenten querbeet durchgereicht und angesprochen, teilweise ganze Forms oder Events. Das Design ist natürlich unglücklich, aber wie so oft, historisch gewachsen. Von daher entstand die Idee, zunächst mal die Abhängigkeiten vom Hersteller zu verstecken... Vermutlich kommen wir aber um ein generelles Re-Design nicht herum. Hat ja auch was Gutes.

    Gruß, Karsten.

    Mittwoch, 2. September 2015 08:04
  • Hi Karsten,

    grundlegend darfst du nicht von dem Controll Erben, sondern musst in deinem Controll eine Klasse der Instanz erzeugen. Dann die Methoden schreiben die du brauchst und und dort die Methoden des 3 Anbieters aufrufen.

    Sollte eigentlich dem Adapter Pattern  der GoF entsprechen, in deren Buch ist auch ein Beispiel (wenn ich mich jetzt richtig erinnere). Ansonsten mal Mono anschauen, da es auf IOS und Windows Lauft, sollte es dort auch eine Abstraktionsebene für die Controlls geben.

    MFG

    Björn

    Mittwoch, 2. September 2015 09:05
  • Wenn du unabhängig von einem Hersteller sein willst, dann müsstest du die Controls alle selber schreiben. Denn im Grunde wärst du bei der Verwendung der "Common Controls" von Windows ja abhängig von Microsoft. Kann sein, dass dich das nicht stört. Wir haben bei uns aber extra ein Projekt gestartet um genau davon loszukommen. Das ist aber natürlich nicht über Nacht gemacht und es artet schnell mal aus. Schliesslich will man ja einen visuellen Dialog Editor dazu haben, Ressourcen kompilieren können und so weiter...

    Wenn du den etwas einfacheren Weg gehen willst, dann müsstest du alle Common Controls von Windows kapseln. Ein gutes Beispiel wie das geht ist der Source Code vom MFC (der wird mit dem Visual Studio mitgeliefert). Daneben könntest du dann auch noch eigene Steuerelemente schreiben und das etwas mixen um die Funktionen erzeugen zu können, die du wirklich brauchst.

    Wenn du jedoch nur die Abhängigkeit in eine gemeinsame Datei verschieben willst, dann musst du genau so vorgehen wie bei der Abhängigkeit von den Common Controls. Du musst alles kapseln. Sprich komplett eigene Klassen und Funktionen bauen und die müssen dann intern das fremde Framework aufrufen. Nur so kriegst du die Abhängigkeit raus. Du darfst in keinem Teil deines Projekts mehr was anderes nutzen als "deine" Control-Klassen.

    Alles in allem... eine recht nervige Aufgabe. Und irgendwie so richtig toll finde ich persönlich nur das eigene GUI Framework... aber wie gesagt, ist halt ein Haufen Arbeit, den man da investieren muss.

    Rudolf


    Montag, 7. September 2015 17:35
  • Hallo Karsten,

    du könntest, um das Chaos zu beenden eine DLL-Komponente als Zwischenschicht einfügen.

    Dazu würdest du dir allerdings schon nicht wenig Arbeit aufdrücken.

    Du müsstest für jede Klasse (jedes UI-Element) ein "UserControl" in Visual Studio anlegen und innerhalb dieses kannst du dann dein Drittanbieter-Element einbinden:

    <!-- Angenommen, du verwendest XAML -->
    <UserControl x:Name="uiRoot" ...>
       <ThirdPartyControl x:Name="uiContent" />
    </UserControl>
    

    Angenommen, die Klasse heißt "UltraButton", dann würde deine Klasse zum Beispiel _UltraButton heißen (oder irgendwie anders, dass man aus dem Namen direkt den originalen Namen lesen kann.)

    Dann dürftest du für jede Eigenschaft, jedes Ereignis und jede Funktion die Benutzt werden soll diese Doppelt implementieren.

    Beispiel:

    // Angenommen, UltraButton hat eine Eigenschaft namens "WTF"
    Dann würdest du eine gleichnamige Wrapper-Eigenschaft erstellen.
    public object WTF {
        get { return uiContent.WTF; } // Auf uiContent (siehe XAML) verweisen
        set { uiContent.WTF = value; } 
    }

    Ähnliches gilt auch für Funktionen und Ereignisse.

    Wie gesagt, würde sich aber nur Lohnen, wenn es anders nicht geht. Es ist nunmal eine Menge schreibarbeit.

    Vielleicht gibt es einen Praktikanten  dafür :D

    PS: Du kannst die DLL des Drittanbieters auch in deine Wrapper-DLL einbauen: Github: Costura (Nugget für VS)


    © 2015 Thomas Roskop
    Germany //  Deutschland

    Montag, 7. September 2015 18:25
  • Hallo und vielen Dank für die vielen Antworten. So richtig durchringen konnte ich mich noch nicht. Unser Ursprungsproblem ist ja eigentlich *nur*, dass wir Infragistics nicht aktualisieren können, da die ganzen DLLs voneinander abhängig sind und somit eine DLL mit Infragistics Version A nicht mit einer DLL mit Infragistics Version B harmoniert. Da wäre das Schreiben eigener Controls vielleicht doch etwas übertrieben. Ich denke, ich werde an der Architektur arbeiten und versuchen, die Abhängigkeiten aufzulösen.

    Gruß, Karsten.

    Mittwoch, 9. September 2015 06:53