Skip to main content

What are the base async patterns in .NET world

In momentul de fata exista diferite paternuri care sunt folosite pentru apeluri asyncrone. Am observat ca destul de multa lume incurca aceste paternuri si se face un mix intre acestea.
Din cate am observat pana acuma exista 3 paternuri principale care sunt folosite in general in .NET (mai putin 4.5, despre care o sa vorbim separat).
EAP (Event based Asynchronous Pattern) - in acest patern orice schimbare de stare (actiune se termina de executat, apare o eroare, progresul) sunt notificate prin intermediul unor evenimente.
public class FooEAP
{   
    public void CalculateAsync(int value1, int value2)
{
    int sum = value1 + value2;
    OnCalculateComplete(sum);
}
public event CalculateCompleteEventHandler CalculateComplete;
private void OnCalculateComplete(int result)
{
    if( CalculateComplete != null )
    {
        CalculateComplete(this, new FooCalculateEventArgs(result));
    }
}
}
APM (Asynchronous Programming Model) - paternul este destul de usor de recunoscut prin formatul BeginXXX si EndXXX. In momentul in care un utilizator apeleaza BeginXXX, task-ul incepe sa se execute. Aceasta metoda o sa returneze o implementare a interfetei IAsyncResult care are urmatoarea forma:
public interface IAsyncResult
{
WaitHandle AsyncWaitHandle { get; }
Boolean    IsCompleted     { get; }
Object     AsyncState      { get; }
Boolean    CompletedSynchronously { get; }
}
Aceasta interfata se poate folosii pentru a verifica in ce stare se afla actiunea noastra sau sa vedem progresul. Acest patern este destul de intalnit in WCF.
public class FooAPM
{
    IAsyncResult calculateAsyncResult;
    public IAsyncResult BeginCalculate(int value1, int value2)
{
    ...   
}
    public void EndInvoke()
{
    // Wait the task to finish
}
}
TPL (Task Parallel Library) - se bazeaza pe task-uri care au fost introduse cu .NET 4.0. Nu reprezinta un patern in sine, dar din .NET 4.5 mai ales o sa fim nevoiti sa le folosim din ce in ce mai des. In general acestea se foloseste cand lucram cu API care se bazeaza pe task-uri. TPL simplifica foarte mult paternul asyncron. Folosind TPL ne este mult mai usor sa scriem si sa folosim cod asyncron.
public class FooTPL
{
    public Task<int> Calculate(int value1, int value2)
{
    return new Task<int>(() => { return value1 + value2; });
}
}
Task-urile sunt destul de complexe din puct de vedere a API-ului. Sunt extrem de usor de folosit, dar trebuie folosite cu cap deoarece pot sa faca mai mult rau decat bine.
Odata cu .NET 4.5 au aparut async si await, iar orice apel poate sa fie executat asyncron fara sa mai scrim nici o linie de cod. In spate ele se bazeaza pe task-uri si fac parte din TPL si vin in ajutor programatorului. Folosinf aceste doua chei ne este multi mai usor sa scriem si sa facem apeluri asyncrone. In general aceste metode sunt denumite sub forma XXXAsync.
public class FooTPL
{
    public async Task<int> CalculateAsync(int value1, int value2)
{   
    int sum = await CalculateHelper.SumAsync(value1, value2);
return sum;
}
}
Despre cum functioneaza await, o sa revin intr-un post viitor.
Sper ca dupa citirea acestui post va este putin mai clar fiecare din aceste "paternuri". Toate fac acelasi lucru, doar ca in diferite moduri.

Comments

Popular posts from this blog

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Can User Technical Profile Influence AI Architecture Decisions?

In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see...