2011-08-01 5 views
0

J'utilise Silverlight avec les services RIA, qui sont asynchrones par nature. La question n'est cependant pas spécifique à ce choix technologique.Rappel de l'API asynchrone Question de conception

Je veux boucler un appel asynchrone, pour un service web par exemple, et fournir ma propre API simplifiée et faiblement couplée (ex: repository sur DomainClient).

, je Jusqu'à présent, le style suivant des méthodes asynchrones dans mes interfaces:

public void DoAsyncWork(Action<AsyncWorkResult<someResultType>> callback); 

et j'envisage d'ajouter les suivantes: les surcharges

public void DoAsyncWork(Action<someResultType> onSuccess, 
         Action<Exception> onException); 

et

public void DoAsyncWork(Action<someResultType> onSuccess, 
         Action<Exception> onException, 
         Action finally); 

l'action onSuccess ne s'exécuterait que si l'appel asynchrone aboutissait y, le onException s'exécute en cas d'erreur signalée par l'appel, et le finally sera exécuté à la fin dans les deux cas. Ma question est, ayant mis en œuvre le premier style qui est un peu "le général", et le plus utilisé (autant que je sache), devrais-je implémenter les deux autres? valent-ils l'investissement dans le développement et la maintenance?

Cette question concerne l'aspect de la conception, indépendamment de toutes les exigences.

Merci à l'avance :)

+0

@Cory: Je n'ai pas ajouté la balise "Silverlight" ici, car comme je l'ai dit, je me concentre uniquement sur l'aspect de la conception de l'API. Merci quand même :) – AbdouMoumen

+0

Les meilleurs designs d'API peuvent être très différents selon la langue/le framework que vous utilisez. Je dirais que c'est une information importante, mais peut-être pas. –

+0

@Cory: OK, assez juste :) Mais où est allé votre réponse? Je n'ai pas utilisé le modèle dont vous avez beaucoup parlé et j'allais en apprendre plus à ce sujet. Ensuite, j'ai trouvé votre réponse a disparu: s – AbdouMoumen

Répondre

0

Je dirais que garder une très bonne, API cohérente si possible.

Il est probablement préférable d'imiter les API async qui existent déjà dans .NET, qui vous permettent d'utiliser la syntaxe de gestion des exceptions intégrée:

public IAsyncResult BeginAsyncWork(AsyncCallback callback, object state); 
public SomeResultType EndAsyncWork(IAsyncResult res); 

qui est utilisé comme:

BeginAsyncWork(res => 
{ 
    // BeginAsyncWork calls this once it completes, even on error. 

    // res is IAsyncResult -- the same one BeginAsyncWork returns. 
    // res.AsyncState is whatever the users passed in the 'state' parameter. 

    try 
    { 
     // To get the result, and possibly an exception, EndAsyncWork is called. 
     SomeResultType r = EndAsyncWork(res); 
    } 
    catch(Exception ex) 
    { 
     // EndAsyncWork throws the exception. 
    } 
    finally 
    { 
     // 
    } 
}, null);