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

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

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

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too