come modulare i servizi wcf?

Una soluzione è creare interfacce WCF che supportano l'estensibilità. Cioè, invece di chiamare semplicemente un metodo con un set fisso di parametri, considera la possibilità di chiamare un metodo che prende come parametro un identificatore (che potrebbe essere un numero intero) affinché il metodo venga chiamato internamente. I parametri per il metodo secondario sono impacchettati come una matrice di istanze di classe passate come un singolo parametro al metodo WCF.

Avresti bisogno di più informazioni per sapere con certezza cosa fare qui.

La mia inclinazione naturale sarebbe verso l'utilizzo di metodi web WCF che richiede un parametro identificativo. Il tuo metodo web avrebbe un numero qualsiasi di parametri necessario in base ai tuoi requisiti (sebbene la mia preferenza in questa situazione sarebbe quella di fornire parametri relativi alla logica come una matrice contenente coppie chiave / valore e tutti i parametri identificatori sono argomenti separati) con un parametro un numero di versione o un ID app.

Il codice interno del tuo metodo web WCF agirà come un router, instradando i valori recuperati al metodo interno corretto per elaborare i risultati in base all'applicazione o al numero di versione di destinazione.

Ad esempio, è possibile che app1, app2 e app3 utilizzino tutti la stessa versione di un metodo ipotetico DoSomething() mentre app4 ha alcuni requisiti logici aggiuntivi. Possono tutti condividere lo stesso contratto operativo e il servizio web, mentre in realtà vengono gestiti in modo diverso sotto il cofano. La cosa positiva di questo approccio è che se app5, 6 e 7 emergono in futuro non è necessario interrompere l'operazione esistente contratti.

Considera quanto segue:

[ServiceContract]

public interface IApplicationService
{
    [OperationContract]
    [WebGet(UriTemplate = "/DoSomething?appId={appId}&parms={parms}")]
    ResponseObj DoSomething(string appId, string[] parms);
}


public class ApplicationService: IApplicationService {
public ResponseObj DoSomething(string appId, string[] parms)
{
    ResponseObj retVal;
    switch(appId)
    {
         case "app1":
         case "app2":
         case "app3":
             retVal = DoSomething(parms);
             break;
         case "app4":
             retVal = DoSomethingElse(parms);
             break;
         default:
             // Handle case
             break;
    }
    return retVal;
}
private ResponseObj DoSomething(string[] parms) { /**logic!**/ }
private ResponseObj DoSomethingElse(string[] parms) { /**logic!**/ }
}

[DataContract]
public class ResponseObj { /**data members**/ }

Con qualcosa del genere il tuo contratto operativo non cambia mai. Se si modifica qualcosa per la logica in App4, ad esempio, non ha effetto su 1, 2 o 3. Tuttavia, la documentazione dell'API dovrebbe essere chiara sul formato dell'array previsto e i metodi privati dovranno convalidare la dati recuperati.

A seconda di come sono configurate le cose, puoi fare le cose in altri modi. Ad esempio, se il tuo servizio web ha un metodo login () che restituisce una sessione, puoi legare la versione alla sessione. Ora il tuo routing si basa sullo stato della sessione che stai monitorando sul server, e puoi facilmente estrapolarlo nel codice framework senza dover ingombrare i tuoi metodi di business logic.

Personalmente non ho usato MEF con WCF, solo MVC4, quindi non posso commentare quanto bene sarebbe adatto al tuo caso d'uso qui. La soluzione che ho fornito non si basa su MEF ma è piuttosto costosa da mantenere nel tempo man mano che si inizia il ridimensionamento verso più app utilizzando un servizio condiviso. Ho costruito qualcosa di simile per un ex datore di lavoro altrove, sebbene fosse un'astrazione per un database di controllo che forniva dati di configurazione per diverse app registrate tramite appId.