locked
WCF BusinessLogic Strukturierung RRS feed

  • Frage

  • hi

    habe einen wcf service der im laufe der zeit sehr viele methoden bekommen wird,
    da ich aber über 1 ServiceClient objekt im client zugreifen möchte/muss würde ich
    nun gerne dies business logic methoden im service strukturieren

    am liebsten wäre mir sub-klassen zu machen damit ich zb folgendes machen kann:
         ServiceClient proxy .....
         proxy.getTopicAManager().getListeA();
         proxy.getTopicBManager().getListenObjektB(string id);
    ....also quasi die methoden im service nach themen unterteilen und diese in den subklassen verschachteln

    eigentlich müsste ich die subklassen ja soweit ich glaube wiederum als interface umsetzen, was aber
    auch nicht wirklich was gebracht hat

    hat wer ne idee bzw. best practise?

    cheers
    Mittwoch, 22. Juli 2009 12:40

Antworten

  • hallo,
    also sehr interessant finde ich folgenden Ansatz, auch wenn er am Anfang ordentlich verwirrt.
    http://www.codeproject.com/KB/WPF/LtoE.aspx#WCF

    Aber du hast schon recht. Irgendwie ist es nicht leicht sich WCF zugänglich zu machen.
    Guck Dir doch mal folgendes an:
    http://de.wikipedia.org/wiki/Serviceorientierte_Architektur

    Gruss 
    Montag, 7. September 2009 22:07
  • Ich finde, der dort gemachte Vorschlag ist nicht allgemein richtig. In einem Framework kann es ein sehr sinnvoller Ansatz sein, solche Signaturen zu haben:
    Object handle(IGotData o)
    Der Service kann dann e.g. mittels o.GetData() generisch alle Objekte bedienen. Ob dies ein valider Ansatz für das hier gestellt Problem der Schnittstellenübersicht ist, finde ich eher nicht. Natürlich ist die Schnittstelle durch diesen Ansatz aufgeräumt, aber selbsterklärend ist sie nicht mehr.

    Ich fände, die parametrisierung solch eines Aufrufes, quasi als Light-Version des radikalen Vorschlags, für das ursprünglich gefragte Problem besser:
    List GetList(TopicManager tm, ListType lt);
    List GetList(TopicManager tm, ListType lt, string id);
    
    Je nach Anwendungsfall und komplexität, TopicManager und ListType durch Enums ersetzen und diese als Enums sharen.

    Gruß

    Eike
    Samstag, 24. Oktober 2009 18:25

Alle Antworten

  • hallo,
    also sehr interessant finde ich folgenden Ansatz, auch wenn er am Anfang ordentlich verwirrt.
    http://www.codeproject.com/KB/WPF/LtoE.aspx#WCF

    Aber du hast schon recht. Irgendwie ist es nicht leicht sich WCF zugänglich zu machen.
    Guck Dir doch mal folgendes an:
    http://de.wikipedia.org/wiki/Serviceorientierte_Architektur

    Gruss 
    Montag, 7. September 2009 22:07
  • Hallo boxblinkracer,

    Hat Dir die Antwort geholfen?

    Grüße,
    Robert

    Mittwoch, 16. September 2009 09:08
    Moderator
  • Hallo boxblinkracer,

    Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert

    Samstag, 19. September 2009 19:33
    Moderator
  • Ich finde, der dort gemachte Vorschlag ist nicht allgemein richtig. In einem Framework kann es ein sehr sinnvoller Ansatz sein, solche Signaturen zu haben:
    Object handle(IGotData o)
    Der Service kann dann e.g. mittels o.GetData() generisch alle Objekte bedienen. Ob dies ein valider Ansatz für das hier gestellt Problem der Schnittstellenübersicht ist, finde ich eher nicht. Natürlich ist die Schnittstelle durch diesen Ansatz aufgeräumt, aber selbsterklärend ist sie nicht mehr.

    Ich fände, die parametrisierung solch eines Aufrufes, quasi als Light-Version des radikalen Vorschlags, für das ursprünglich gefragte Problem besser:
    List GetList(TopicManager tm, ListType lt);
    List GetList(TopicManager tm, ListType lt, string id);
    
    Je nach Anwendungsfall und komplexität, TopicManager und ListType durch Enums ersetzen und diese als Enums sharen.

    Gruß

    Eike
    Samstag, 24. Oktober 2009 18:25