none
MEF : Konfiguration der Module RRS feed

  • Frage

  • Hallo Comm,

    ich stehe nun wieder vor einer neuen Herausforderung :

    Wie Löse ich Konfigurationen der Module ?

    Bsp.

    ClassA implementiert InterfaceA

    ClassB implementiert IntefaceA

    Beide brauchen eien Config , nur braucht Klasse B mehr Infos

    ClassA braucht (string Server , string Port)

    ClassB braucht (string Server,string Port,bool Secure)

    Was wäre hierfür nun die Best Practise ?

    macht es Sinn das jede Klasse eine Konfiguration für sich hat ?

    Soll die App.Config genutzt werden (Obwohl es unsicher ist)

    Grüße

    Mittwoch, 3. November 2010 14:08

Antworten

  • Hallo Pawel,

    mit der Best Practice ist das so eine Sache. Das ist wie beim Häuserbau:
    Das Fundament sollte darauf ausgelegt sein, das zu bauende Haus dauerhaft zu tragen.

    Und bevor man sich über Konfigurationsdateien (den Einzug) Gedanken macht,
    wäre eine Bauzeichnung (und bei Großvorhaben auch ein Modell) eine gute Idee.

    Etwas konkreter:
    Hier wäre zu überlegen, welcher Verwendung die beiden Klassen zugeführt werden sollen.
    Da man mit A und B wenig anfangen kann, nehme ich mal an,
    es handelt um eine Übertragung (von Dateien o. ä.).
    Die im erten Falle nur ungesichert, im zweiten Falle optional gesichert erfolgen kann.
    Und die Anmeldeinformationen über einen Konstruktor übergeben werden -
    was z. B. via Injection erfolgen könnte, was aber für die "Bauzeichung" erstmal belanglos ist.

    Das könnte man dem Häuserbau entsprechend als zwei Eingänge betrachten.
    Der erste lässt jeden rein, der einen Schlüssel hat, der zweite benötigt optional
    noch eine zusätzliche Information.

    In Schnittstellen gepresst gäbe es nun als Möglichkeit, eine Schnittstelle beide Möglichkeiten anzubieten.

    Dann hätte müsste der erste Eingang (ClassA)  auch die durchlassen, die einen sicheren
    Zugang haben möchten. Und die Frage wäre,  ob man das gewillt ist zuzulassen
    (z. B. jemanden in seine Privaträume zu lassen).

    Will man das nicht, müsste man denjenigen abweisen - was in Software z. B. eine Ausnahme wäre.
    Und derjenige müsste einen weiteren Eingang suchen, der in (gnädigerweise) reinlässt.
    (Was zeitaufwändig und einem trial by error entspräche)

    Die Alternative wäre, zwei Schnittstellen zu verwenden (z. B. das zweite SecureInterfaceA)
    Die zweite könnte hier auf InterfaceA aufbauen (und in dem Falle einen ungesicherten Zugang
    ermöglichen).

    Derjenige, der (nur/auschliesslich) nach einem sichereren Zugang sucht,
    kann dies über SecureInterfaceA tun. Und muss sich nicht über diverse
    Abweisungen (Ausnahmen, etc.) den "richtigen" Eingang suchen.
    Kriegt er den nicht, bleibt geht er wieder weg.

    So kann der Nutzer der Klassen/Schnittstellen am Ende entscheiden,
    ob er nur (oder lieber) sicher gehen möchte. Und wenn das nicht möglich ist,
    auch sich den allgemeinen Zutritt verschafft.

    Ich hoffe, meine Überlegungen/Ausführungen waren einigermaßen verständlich.
    Wie Du diese Bauzeichnung in ein Haus (MEF) umsetzt, muß ich Dir (oder anderen) überlassen,
    da mein Baustil derzeit ein anderer ist ;-)

    Gruß Elmar

    Donnerstag, 4. November 2010 10:18
    Beantworter
  • hi Leute,

    so ich habe mir meine Frage nun nach mehreren anläufen selbst beantwortet :

    Am besten übergebe ich jedem Projekt ein Config Interface.

    Das ganze ist dann auch quasi  nach dem DI Prinzip ;-)

    Den einzelnen Module eine eigenständig Konfig zu geben ist nicht anzuraten.

     

    Grüße

    Dienstag, 30. November 2010 14:13

Alle Antworten

  • Hallo Pawel,

    mit der Best Practice ist das so eine Sache. Das ist wie beim Häuserbau:
    Das Fundament sollte darauf ausgelegt sein, das zu bauende Haus dauerhaft zu tragen.

    Und bevor man sich über Konfigurationsdateien (den Einzug) Gedanken macht,
    wäre eine Bauzeichnung (und bei Großvorhaben auch ein Modell) eine gute Idee.

    Etwas konkreter:
    Hier wäre zu überlegen, welcher Verwendung die beiden Klassen zugeführt werden sollen.
    Da man mit A und B wenig anfangen kann, nehme ich mal an,
    es handelt um eine Übertragung (von Dateien o. ä.).
    Die im erten Falle nur ungesichert, im zweiten Falle optional gesichert erfolgen kann.
    Und die Anmeldeinformationen über einen Konstruktor übergeben werden -
    was z. B. via Injection erfolgen könnte, was aber für die "Bauzeichung" erstmal belanglos ist.

    Das könnte man dem Häuserbau entsprechend als zwei Eingänge betrachten.
    Der erste lässt jeden rein, der einen Schlüssel hat, der zweite benötigt optional
    noch eine zusätzliche Information.

    In Schnittstellen gepresst gäbe es nun als Möglichkeit, eine Schnittstelle beide Möglichkeiten anzubieten.

    Dann hätte müsste der erste Eingang (ClassA)  auch die durchlassen, die einen sicheren
    Zugang haben möchten. Und die Frage wäre,  ob man das gewillt ist zuzulassen
    (z. B. jemanden in seine Privaträume zu lassen).

    Will man das nicht, müsste man denjenigen abweisen - was in Software z. B. eine Ausnahme wäre.
    Und derjenige müsste einen weiteren Eingang suchen, der in (gnädigerweise) reinlässt.
    (Was zeitaufwändig und einem trial by error entspräche)

    Die Alternative wäre, zwei Schnittstellen zu verwenden (z. B. das zweite SecureInterfaceA)
    Die zweite könnte hier auf InterfaceA aufbauen (und in dem Falle einen ungesicherten Zugang
    ermöglichen).

    Derjenige, der (nur/auschliesslich) nach einem sichereren Zugang sucht,
    kann dies über SecureInterfaceA tun. Und muss sich nicht über diverse
    Abweisungen (Ausnahmen, etc.) den "richtigen" Eingang suchen.
    Kriegt er den nicht, bleibt geht er wieder weg.

    So kann der Nutzer der Klassen/Schnittstellen am Ende entscheiden,
    ob er nur (oder lieber) sicher gehen möchte. Und wenn das nicht möglich ist,
    auch sich den allgemeinen Zutritt verschafft.

    Ich hoffe, meine Überlegungen/Ausführungen waren einigermaßen verständlich.
    Wie Du diese Bauzeichnung in ein Haus (MEF) umsetzt, muß ich Dir (oder anderen) überlassen,
    da mein Baustil derzeit ein anderer ist ;-)

    Gruß Elmar

    Donnerstag, 4. November 2010 10:18
    Beantworter
  • Hallo Elmar,

     

    ich musste bei deinem text schmunzeln.

    In einer "nicht MEF" Anwendung hätte ich es zumindest fast so wie du es beschrieben hast gemacht (mehrere Methoden oder anderes Inetrface). Ich dachte mir vll. gibt es durch MEF andere Methoden.

    Vorallem habe ich MEF so verstanden das der Host nicht für das zuständig ist was die Module ansich machen, wurde aber durch diverse Artikel eines besseren belehrt, MEF ist eben nur zum teil ein DI Framework ;-)

    Trotzdem Danke für deine doch unterhaltsame Ausführung :-)

    Grüße

    Pawel

    Donnerstag, 4. November 2010 10:51
  • Hallo Pawel,

    wenn Du "schmunzeln" konntest, war die Unterhaltung die Mühe wert.

    Leider scheint das Thema aber keine weiteren Interessenten anzulocken...

    Gruß Elmar

    Montag, 8. November 2010 13:19
    Beantworter
  • Hallo Elmar,

    das habe ich auch festgestellt, entweder erstellt keiner Software mit MEF oder MEF ist noch zu neu ...

    Wer weiß, ich werds auf jeden Fall weiter nutzen ;-)

    Gruß Pawel

    Montag, 8. November 2010 13:22
  • hi Leute,

    so ich habe mir meine Frage nun nach mehreren anläufen selbst beantwortet :

    Am besten übergebe ich jedem Projekt ein Config Interface.

    Das ganze ist dann auch quasi  nach dem DI Prinzip ;-)

    Den einzelnen Module eine eigenständig Konfig zu geben ist nicht anzuraten.

     

    Grüße

    Dienstag, 30. November 2010 14:13