Maintaining consistency across numerous processes can be difficult in the world of distributed systems and microservices architecture. The Saga pattern saves the day by managing a series of distributed transactions to ensure data consistency without relying on a two-phase commit process. In this post, we'll look at how to implement the Saga pattern with Rebus, a versatile.NET messaging package, and RabbitMQ, a sophisticated message broker.

What exactly is the Saga Pattern?
The Saga pattern, at its core, maintains a chain of local transactions, with each step representing a transaction involving distinct services or components. If any step fails, compensating actions are taken to ensure overall consistency.

Sagas ensure that either all operations within the sequence succeed or, in the case of failure, the system reverts to a consistent state by executing compensating actions.
Using Rebus and RabbitMQ

Setting Up Rebus and RabbitMQ

To begin, install the necessary packages using NuGet.
Install-Package Rebus
Install-Package Rebus.RabbitMQ

Next, configure Rebus and RabbitMQ:
var configurer = Configure.With(...)
    .Transport(t => t.UseRabbitMq("amqp://localhost", "saga-example"))
    .Start();

Implementing a Saga
Let's consider a hypothetical e-commerce scenario where a customer places an order consisting of multiple steps: reserve items, charge payment, and ship items. We'll implement a saga to manage these operations.
public class OrderSagaData
{
    public Guid OrderId { get; set; }
    public bool ItemsReserved { get; set; }
    public bool PaymentCharged { get; set; }
    public bool ItemsShipped { get; set; }
}

public class OrderSaga : Saga<OrderSagaData>,
    IAmInitiatedBy<PlaceOrder>,
    IHandleMessages<ReserveItems>,
    IHandleMessages<ChargePayment>,
    IHandleMessages<ShipItems>
{
    // Saga implementation here
}

Handling Messages in the Saga
Each message represents a step in the saga. For instance, the PlaceOrder message initiates the saga.
public class PlaceOrder
{
    public Guid OrderId { get; set; }
    public List<Item> Items { get; set; }
}

public async Task Handle(PlaceOrder message)
{
    Data.OrderId = message.OrderId;
    // Reserve items logic
    Bus.Send(new ReserveItems { OrderId = message.OrderId, Items = message. Items });
}

Similarly, other messages like ReserveItems, ChargePayment, and ShipItems are handled within the saga, managing the respective operations and updating saga data accordingly.

Compensating Actions
Should any step fail, compensating actions ensure the system maintains consistency. For instance, if charging payment fails, a compensating action might be implemented as follows.
public async Task Handle(ChargePayment message)
{
    // Charge payment logic
    if (paymentFailed)
    {
        // Execute compensating action
        Bus.Send(new CancelOrder { OrderId = Data.OrderId });
    }
}

Implementing the Saga pattern using Rebus and RabbitMQ offers a powerful way to manage distributed transactions and maintain data consistency in a microservices architecture. By orchestrating a sequence of steps and incorporating compensating actions, sagas ensure system integrity despite failures within the distributed environment.

The Visitor Pattern is used in an ASP.NET Core Web API with a 3-tier design for efficient data manipulation in the C# Article model. The model, CSharpArticle, contains critical features. A Data Access Layer with a repository manages database interactions, a Business Layer with the Visitor interface and Article Service, and a Presentation Layer with the API controllers comprise the architecture. In the Business Layer, the Visitor Pattern is used to conduct operations on articles, allowing for clean separation of responsibilities and enabling reusable, structured, and scalable code. This architecture ensures that CRUD activities benefit from the flexibility of the Visitor Pattern while preserving a clear division of responsibilities across the application layers.

Overview of Three-Tier Architecture
The Presentation Layer manages the API controllers and interacts with the client.
The business logic, data validation, and any special business rules are all contained in the business layer.
Data Access Layer: Manages data retrieval and storage, as well as database interaction.

Article Model in C#
Let's start with the Article model.
public class CSharpArticle
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
}

Data Access Layer
Repository Interface:
public interface IArticleRepository
{
    CSharpArticle GetArticleById(int id);
    void AddArticle(CSharpArticle article);
    void UpdateArticle(CSharpArticle article);
    void DeleteArticle(int id);
}

Repository Implementation:
public class ArticleRepository: IArticleRepository
{
    private readonly CSharpCornerArticleProject _context;

    public ArticleRepository(YourDbContext context)
    {
        _context = context;
    }

    public CSharpArticle GetArticleById(int id)
    {
        return _context.Articles.FirstOrDefault(a => a.Id == id);
    }

    public void AddArticle(CSharpArticle article)
    {
        _context.Articles.Add(article);
        _context.SaveChanges();
    }

    public void UpdateArticle(CSharpArticle article)
    {
        _context.Articles.Update(article);
        _context.SaveChanges();
    }

    public void DeleteArticle(int id)
    {
        var article = _context.Articles.FirstOrDefault(a => a.Id == id);
        if (article != null)
        {
            _context.Articles.Remove(article);
            _context.SaveChanges();
        }
    }

    public void Accept(IArticleVisitor visitor, int articleId)
    {
        var article = GetArticleById(articleId);
        visitor.Visit(article);
        UpdateArticle(article);
    }
}

Business Layer
Visitor Interface
public interface IArticleVisitor
{
    void Visit(CSharpArticle article);
}

public class ContentAnalyzerVisitor: IArticleVisitor
{
    public void Visit(CSharpArticle article)
    {
        if (article != null)
        {
            int wordCount = CountWords(article.Content);
            bool hasKeywords = CheckForKeywords(article.Content);

            article.WordCount = wordCount;
            article.HasKeywords = hasKeywords;
        }
    }

    private int CountWords(string content)
    {
        if (string.IsNullOrWhiteSpace(content))
            return 0;

        string[] words = content.Split(new char[] { ' ', '.', ',', ';', '!', '?' }, StringSplitOptions.RemoveEmptyEntries);
        return words.Length;
    }

    private bool CheckForKeywords(string content)
    {
        string[] keywordsToCheck = { "C#", "ASP.NET", "Entity Framework" }; if needed
        foreach (string keyword in keywordsToCheck)
        {
            if (content.Contains(keyword, StringComparison.OrdinalIgnoreCase))
            {
                return true;
            }
        }
        return false;
    }
}

Article Service:
public class ArticleService
{
    private readonly IArticleRepository _repository;

    public ArticleService(IArticleRepository repository)
    {
        _repository = repository;
    }

    public void Accept(IArticleVisitor visitor, int articleId)
    {
        CSharpArticle article = _repository.GetArticleById(articleId);
        visitor.Visit(article);
        _repository.UpdateArticle(article);
    }

    public void Publish(int articleId)
    {
        CSharpArticle article = _repository.GetArticleById(articleId);
        article.Publish();
        _repository.UpdateArticle(article);
    }

    public void Archive(int articleId)
    {
        CSharpArticle article = _repository.GetArticleById(articleId);
        article.Archive();
        _repository.UpdateArticle(article);
    }
}

Presentation Layer (Controller)
Controller:
[Route("api/articles")]
[ApiController]
public class CSharpArticleController : ControllerBase
{
    private readonly ArticleService _articleService;

    public CSharpArticleController(ArticleService articleService)
    {
        _articleService = articleService;
    }

    [HttpGet("{id}")]
    public IActionResult Get(int id)
    {
        var article = _articleService.GetArticle(id);
        if (article == null)
        {
            return NotFound();
        }
        return Ok(article);
    }

    [HttpPost]
    public IActionResult Post([FromBody] CSharpArticle article)
    {
        if (article == null)
        {
            return BadRequest();
        }
        _articleService.CreateArticle(article);
        return CreatedAtAction("Get", new { id = article.Id }, article);
    }

    [HttpPut("{id}")]
    public IActionResult Put(int id, [FromBody] CSharpArticle article)
    {
        if (id != article.Id)
        {
            return BadRequest();
        }
        _articleService.UpdateArticle(article);
        return NoContent();
    }

    [HttpDelete("{id}")]
    public IActionResult Delete(int id)
    {
        var existingArticle = _articleService.GetArticle(id);
        if (existingArticle == null)
        {
            return NotFound();
        }
        _articleService.DeleteArticle(id);
        return NoContent();
    }
}

Conclusion
This structure separates concerns and enables the Visitor Pattern to conduct actions on the Article model across levels, maintaining logical separation and reusability. The repository, service, and controller implementations may alter depending on the database, ORM, or particular requirements of your application. While the Visitor Pattern can be useful in some situations, it may not be required for every CRUD action. Always evaluate the pattern's true need in the context of your application's complexity and requirements.

The implementation of the Visitor Pattern for C# Article management in an ASP.NET Core Web API following a 3-tier design provides a strong structure for managing CRUD activities. The CSharpArticle model is at the heart of data operations, which are governed by the Data Access Layer via the ArticleRepository. This repository communicates with the database and supports CRUD operations. The Business Layer, represented by the ArticleService, orchestrates operations on articles by utilizing the Visitor Pattern to perform specified tasks via visitors such as content analysis, publishing, archiving, and other appropriate actions.The Presentation Layer's CSharpArticleController serves as the interface for external interactions. It interfaces with the ArticleService to handle HTTP requests, allowing it to get, create, update, and delete articles. Each method correlates to an HTTP verb, allowing for smooth communication with the underlying layers and, ultimately, efficient and controlled article administration.

This hierarchical architecture enables code that is modular, scalable, and maintainable. It allows the program to handle additional features or changes without interfering with core functionality. The application of the Visitor Pattern within the three-tier architecture increases the system's flexibility by fostering a clear separation of responsibilities and improving the API's overall performance and maintainability.

Database access is an important component of application development, and optimizing it is key for overall speed and user experience. C# is a flexible language used for building robust applications in the.NET ecosystem. Using actual examples, we'll look at numerous ways for improving database access in.NET.

1. Select the Best Data Access Technology
Let's start by looking at several data access mechanisms in.NET and offering examples of how to use them effectively.
Example: ADO.NET
using System;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        string connectionString = "YourConnectionString";

        using (SqlConnection connection = new SqlConnection(connectionString))
        {
            connection.Open();

            // Perform database operations using SqlCommand, SqlDataReader, etc.

            connection.Close();
        }
    }
}

Example: Entity Framework
using System;
using System.Linq;

class Program
{
    static void Main()
    {
        using (var context = new YourDbContext())
        {
            // Use LINQ queries to interact with the database
            var result = context.YourEntity.Where(e => e.SomeProperty == "SomeValue").ToList();
        }
    }
}

Example: Dapper
using System;
using System.Data;
using System.Data.SqlClient;
using Dapper;

class Program
{
    static void Main()
    {
        string connectionString = "YourConnectionString";

        using (IDbConnection dbConnection = new SqlConnection(connectionString))
        {
            // Use Dapper for simplified data access
            var result = dbConnection.Query("SELECT * FROM YourTable WHERE SomeProperty = @SomeValue", new { SomeValue = "SomeValue" });
        }
    }
}

2. Optimize Database Queries
Efficiently constructing queries is crucial for optimal database performance. Let's look at examples of query optimization.
Example: Parameterized Queries
using System;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        string connectionString = "YourConnectionString";

        using (SqlConnection connection = new SqlConnection(connectionString))
        {
            connection.Open();

            string parameterizedQuery = "SELECT * FROM YourTable WHERE SomeColumn = @SomeValue";

            using (SqlCommand command = new SqlCommand(parameterizedQuery, connection))
            {
                command.Parameters.AddWithValue("@SomeValue", "SomeValue");

                // Execute the command
            }

            connection.Close();
        }
    }
}

Example: Avoid SELECT *
using System;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        string connectionString = "YourConnectionString";

        using (SqlConnection connection = new SqlConnection(connectionString))
        {
            connection.Open();

            // Instead of selecting all columns, specify only the required ones
            string query = "SELECT Column1, Column2 FROM YourTable";

            using (SqlCommand command = new SqlCommand(query, connection))
            {
                // Execute the command
            }

            connection.Close();
        }
    }
}

3. Connection Management
Efficient connection management is vital for optimizing database access. Let's see examples of good connection practices.
Example: Connection Pooling
Connection pooling is automatically handled by ADO.NET, so there's usually no explicit code needed. Ensure that you close connections promptly to allow them to return to the pool.

Example: Async Database Operations
using System;
using System.Data.SqlClient;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        string connectionString = "YourConnectionString";

        using (SqlConnection connection = new SqlConnection(connectionString))
        {
            await connection.OpenAsync();

            // Perform asynchronous database operations

            connection.Close();
        }
    }
}

4. Caching
Implementing caching mechanisms can significantly reduce the need for repeated database queries. Let's look at examples of result caching.
Example: Result Caching
using System;
using System.Collections.Generic;
using System.Runtime.Caching; // Use MemoryCache for simplicity

class Program
{
    static void Main()
    {
        // Check if data is in cache
        var cachedData = MemoryCache.Default.Get("YourCachedDataKey") as List;

        if (cachedData == null)
        {
            // Data not in cache, retrieve from the database
            // ...

            // Cache the data
            MemoryCache.Default.Add("YourCachedDataKey", dataFromDatabase, DateTimeOffset.UtcNow.AddMinutes(10));
        }
        else
        {
            // Use the cached data
        }
    }
}

5. Monitoring and Profiling
Monitoring and profiling database interactions help identify bottlenecks. Let's see examples of logging.
Example: Logging
using System;
using System.Diagnostics;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        string connectionString = "YourConnectionString";

        using (SqlConnection connection = new SqlConnection(connectionString))
        {
            connection.Open();

            // Log the start time
            Stopwatch stopwatch = Stopwatch.StartNew();

            // Perform database operations using SqlCommand, SqlDataReader, etc.

            // Log the end time
            stopwatch.Stop();
            Console.WriteLine($"Query executed in {stopwatch.ElapsedMilliseconds} milliseconds");

            connection.Close();
        }
    }
}

Optimizing database access in .NET involves choosing the right data access technology, optimizing queries, managing connections efficiently, implementing caching, and monitoring performance. By applying these examples and best practices, you can ensure that your .NET applications have a responsive and performant database layer, contributing to an overall smoother user experience.

Assume you run an online store and, every month, you send a marketing email to consumers who have registered on your site highlighting the latest products from your store in order to increase sales. Your CEO, on the other hand, wants to know how many customers actually open these emails. If you can't pay third-party email tracking solutions, you can utilize the following way to see if your emails have been opened. Create an API first. If our customers open our emails, this API will record the messages they send back.

[ApiController]
[Route("api/[controller]")]
public class EmailTrackingController : Controller
{
    [HttpGet("EmailOpener")]
    public ActionResult EmailOpener(string email, string eventId)
    {
        //Your logic here to capture email & eventId
        //maybe save email and eventID to DB

        byte[] pixel = Convert.FromBase64String("R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7");
        return new FileContentResult(pixel, "image/gif");
    }
}

As you can see, I've built an EmailTracking controller with a GET method called EmailOpener that takes two parameters: email and eventId.

When a customer opens your marketing email, this API is invoked, and their email address, along with the eventId, is provided to it. The email and eventId can then be captured and saved in your database. You might have noticed that I returned the encoded value "R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7."

This isn't just any dummy value; it's a legitimate base64-encoded representation of a tiny transparent GIF image. Assume the short HTML text below is your marketing email for the forthcoming Black Friday Sales.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Black Friday Sales</title>
</head>
<body>
    <h1>Hi, check out our Black Friday Sales!!!</h1>

    <img alt="" src="https://www.mysite.com/EmailTracking/EmailOpener?email=ENCODED_EMAIL_ADDRESS&eventId=BlackFridaySales2023" width="1" height="1" style="border: none; display: block;" />

    <!-- Main content images -->
    <img src="https://www.mysite.com/contents/image/BFD2023.PNG" alt="Black Friday Deals" />

    <!-- Dummy messages -->
    <p>Dummy Message....</p>
    <p>Dummy Message....</p>
    <p>Dummy Message....</p>
</body>
</html>

As you can see in the email, I have included the following html snippet
<img alt="" src="@Email&eventId=BlackFridaySales2023">https://www.mysite.com/EmailTracking/EmailOpener?email=@Email&eventId=BlackFridaySales2023" width="1" height="1" style="border-width: 0px; border-style: solid;" />

This is an HTML image tag with a 1x1 pixel size that contains a link to our EmailOpener API. Because of its small size, the buyer will overlook it when they read our marketing email. As you can see, I used @Email for the email field; this is a variable that will be substituted with the email address of the real recipient.

When a customer reads your email, the 1x1 pixel picture loads and the URL (in this case, "https://www.mysite.com/EmailTracking/EmailOpener?email=@Email&eventId=BlackFridaySales2023") is triggered. This enables us to determine who opened the email and for what event.

Redirect Image Clickable
Some email providers, however, automatically prevent photos from loading and only display the images if the user chooses to view or download them. If this occurs, our 1x1 pixel image will not work because our consumers will not see it in the email, let alone download it.

To avoid this problem, we can include an appealing image in the email along with a call-to-action such as 'Click the image to discover more amazing deals!' We can redirect them to our API and store their email address in our database whenever they click the image.

To help with this, I've included a new API method called RedirectCustomer.
public ActionResult RedirectCustomer(string email, string eventId)
{
    //Your logic here to capture email & eventId
    //maybe save email and eventID to DB

    if (eventId == "BlackFridaySales2023")
    {
        return Redirect("https://www.mysite.com/BFD2023LandingPage");
    }
    else {
    return Redirect("https://www.mysite.com");
    }
}

This function will record the customer's incoming email and route them to the relevant page based on the incoming eventID. If we notice an incoming client with the eventID 'BlackFridaySales2023,' for example, we'll redirect them to our Black Friday Promotions landing page.

Include the following html image element in the email you send to the customer.
<a href="https://www.mysite.com/EmailTracking/RedirectCustomer?email=@email&eventId=BlackFridaySales2023">
     <img alt="Black Friday Promotion 2023" class="fullWidth" src="https://www.mysite.com/Content/images/BFD2023.png" style="display: block; height: auto; border: 0px; max-width: 600px; width: 100%;" title="Black Friday Promotion 2023!" width="600" />
</a>

An image entitled 'BFD2023.png' will be prominently shown in the email sent to our consumers. When the customer clicks on this image, they will be taken to our API at https://www.mysite.com/EmailTracking/RedirectCustomer?email=@Email&eventId=BlackFridaySales2023. At this point, the customer's email address will be saved in our database. This information allows us to track the email open rate, which can then be examined after the offer is over to determine the campaign's reach and effectiveness.

Some Things to Think About
If you intend to service a large number of customers, you must address potential concerns such as database locks, concurrency, and server overload. It is critical to guarantee that your infrastructure can manage a high amount of incoming requests. Furthermore, further coding steps are required to manage concurrency and prevent database locking from a programming standpoint.

ASP.NET Core is a versatile and robust web application framework. Middleware is one of its core characteristics, and it plays a critical role in processing requests and responses as they travel through your application. This post will explain what middleware is, how it works, and why it is necessary for developing powerful online applications in ASP.NET Core.

ASP.NET Core Middleware

In ASP.NET Core, middleware is a collection of components that are added to the application's request processing pipeline. Each middleware component is responsible for processing an incoming request or an outgoing answer. Middleware components can be added, removed, or reordered, allowing developers to tailor the request-handling pipeline to the specific demands of their application.

Middleware can handle a wide range of responsibilities, including authentication, routing, caching, logging, and more. It functions similarly to a chain of building blocks, with each block performing a specified operation on the request or response before passing it on to the next middleware in the pipeline.

The Middleware Anatomy
In ASP.NET Core, middleware components are often implemented as classes with a specified signature. They accept an HTTP context containing information about the incoming request and allow them to modify the answer. This is the fundamental structure of middleware.

public class MyMiddleware
{
    private readonly RequestDelegate _next;

    public MyMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Do something before the next middleware
        // ...

        await _next(context); // Call the next middleware in the pipeline

        // Do something after the next middleware
        // ...
    }
}

In this case, RequestDelegate represents the next middleware in the pipeline, and the InvokeAsync method provides the logic that will run before and after the next middleware.

In Use Middleware
Consider the following example, in which we wish to track the path of each incoming request.

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;

    public LoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Log the request path
        Console.WriteLine($"Request to: {context.Request.Path}");

        await _next(context); // Call the next middleware in the pipeline
    }
}

We can add this middleware to the pipeline in the Startup.cs file.
public void Configure(IApplicationBuilder app)
{
    app.UseMiddleware<LoggingMiddleware>();

    // Other middleware and configuration...
}

Now, every incoming request's path will be logged before it proceeds through the pipeline.

Ordering Middleware
The order in which middleware components are added to the pipeline matters. Middleware is executed in the order it's added, from top to bottom. For example, if you want to perform authentication before routing, you should add authentication middleware before routing middleware.

public void Configure(IApplicationBuilder app)
{
    app.UseAuthentication(); // Add authentication middleware
    app.UseRouting(); // Add routing middleware

    // Other middleware and configuration...
}

Middleware is a fundamental concept in ASP.NET Core, allowing you to modularize and customize request and response processing in your web applications. By understanding how middleware works and how to leverage it effectively, you can build robust and flexible web applications that meet your specific requirements. Whether you're handling authentication, logging, or any other aspect of request processing, middleware is a powerful tool in your ASP.NET Core toolbox.

Asynchronous programming has become an essential aspect of modern software development, and.NET Core (now known as.NET 5,.NET 6,.NET 7, and later.NET 8) provides strong capabilities to make asynchronous processes easier. When working with tasks, you have two fundamental methods at your disposal: WaitAll and WhenAll. These methods enable you to efficiently manage and coordinate several asynchronous operations. In this blog post, we will look at WaitAll and WhenAll in.NET Core and learn about their differences and applications.

The Fundamentals of.NET Core Asynchronous Programming
Before diving into WaitAll and WhenAll, it's critical to understand the principles of.NET Core asynchronous programming. Asynchronous operations allow your application to run numerous tasks at the same time without interrupting the main thread, which improves responsiveness and speed. You deal with tasks in.NET Core, which represent units of work that can run concurrently.

public async Task DoSomeWorkAsync()
{
    // Perform asynchronous operations
    await Task.Delay(1000); // Simulate work
    // Continue with other operations
}

WaitAll - Waiting for All Tasks to Complete
Task.WaitAll is a synchronous method that blocks the current thread until all the provided tasks have completed. It ensures that all tasks finish their execution before allowing the program to proceed further. This is particularly useful when you need to perform actions only when all tasks are done.

async Task PerformMultipleOperationFromWaitllAsync()
{
    WaitAllSample waitAllSample = new WaitAllSample();
    Task task1 = waitAllSample.DoSomeWorkAsync();
    Task task2 = waitAllSample.DoSomeOtherWorkAsync();
    Task.WaitAll(task1, task2);
    Console.WriteLine("All tasks in WaitAll are complete!");

}

Using Task, on the other hand.WaitAll can cause thread blocking and may not be appropriate in all cases, particularly in UI applications where blocking the main thread can result in a frozen interface.

WhenAll - Concurrently Awaiting All Tasks

WhenAll is an asynchronous method that returns a new task that finishes when all of the specified tasks have completed. Rather of blocking the thread, it lets the computer to continue processing other activities or managing user input, which is essential for responsive apps.

async Task PerformMultipleOperationFromWhenAllAsync()
{
    WhenAllExample whenallexample = new WhenAllExample();
    Task task3 = whenallexample.DoSomethingAsync();
    Task task4 = whenallexample.DoSomethingElseAsync();
    await Task.WhenAll(task3, task4);
    Console.WriteLine("All tasks in WhenAll are complete!");
}

Task.WhenAll is better suited for cases in which numerous asynchronous operations must be performed concurrently without blocking the main thread. It is essential for developing responsive and efficient applications.

Important distinctions between WaitAll and WhenAll
Task.WaitAll is a synchronous method that causes the current thread to be blocked, whereas Task.Because WhenAll is asynchronous, additional processes can execute concurrently.
When you wish to wait for all tasks to finish before proceeding, Task.WaitAll is useful, whereas Task.WhenAll allows you to continue performing other tasks while waiting for tasks to complete.
Task.WaitAll may cause thread-blocking, rendering it inappropriate for UI applications, whereas Task.WhenAll is better suited for responsive interfaces.
Task.WaitAll is older and is frequently used in legacy programs, whereas Task.WhenAll is the ideal and modern method of managing many tasks in.NET Core.

Conclusion
Asynchronous programming is a useful technique in.NET Core for improving application responsiveness and performance. Task.Task and WaitAll.WhenAll methods are critical for managing and coordinating several asynchronous tasks. You may make informed selections when selecting the correct strategy for your specific circumstance if you understand their distinctions and use cases. .NET Core delivers the tools you need to build efficient and responsive apps, whether you need to wait for all actions to complete synchronously or proceed with other processes simultaneously.

ASP.NET Core is a versatile and robust web application framework. It offers a comprehensive collection of capabilities for developing strong and scalable applications, with Action Filters being one of the essential aspects that increase its functionality. Action filters allow you to execute code before or after an action method is executed, allowing you to add cross-cutting concerns to your application. In this post, we will look at action filters in ASP.NET Core, learn about their different types, and how to develop custom filters to improve the functionality of your web application.

What exactly are Action Filters?
In ASP.NET Core, action filters are properties that can be applied to controller action methods to do pre- or post-processing. They enable you to add functionality that is executed before or after action methods are invoked. Cross-cutting concerns like as logging, authentication, caching, and others can be implemented via action filters.

There are five types of action filters in ASP.NET Core.

• Authorization Filter
• Resource Filter
• Action Filter
• Result Filter
• Exception Filter

Filter for Authorization
An authorization filter is essential for enforcing authentication and authorisation rules in your web application. Authorization filters are commonly used to guarantee that only authenticated and authorized users have access to certain areas of your application. These filters are run before the action method, allowing you to validate the user's credentials and permissions before granting or denying access. They are an important part of implementing security and access control in ASP.NET Core applications.

Example
Assume you have a controller with an action method to which you wish to limit access based on user roles. In this scenario, we'll use an Authorization Filter to determine whether or not the user has a specified role before granting access to the action method.

First, define a custom Authorization Filter.
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.AspNetCore.Http;
using System;

public class CustomAuthorizationFilter : Attribute, IAuthorizationFilter
{
public void OnAuthorization(AuthorizationFilterContext context)
{
    // Check if the user is in the "Admin" role
    if (!context.HttpContext.User.IsInRole("Admin"))
    {
        // If not, deny access and return a forbidden status
        context.Result = new StatusCodeResult(StatusCodes.Status403Forbidden);
    }
}
}

Next, apply the CustomAuthorizationFilter to your action method.
[CustomAuthorizationFilter] // Apply the custom authorization filter
public IActionResult AdminOnlyAction()
{
// This action is only accessible to users in the "Admin" role
return View();
}

In this example, the CustomAuthorizationFilter is applied to the AdminOnlyAction method. When a user tries to access this action, the filter checks if they are in the "Admin" role using the IsInRole method. If the user is not in the "Admin" role, the filter sets the HTTP response status code to 403 Forbidden, denying access to the action.

Resource Filter
Resource Filters in ASP.NET Core are a type of action filter that allows you to perform actions that affect the entire HTTP request and response, such as modifying response headers or handling global exceptions. These filters execute before any other filter type (Authorization, Action, Result, and Exception filters) have access to the HTTP context and can influence the entire request processing pipeline.

• Global Exception Handling: Resource filters can be used to handle exceptions that occur during the request processing pipeline. By implementing a resource filter for exception handling, you can catch and handle exceptions globally, providing a consistent way to log errors, display custom error pages, or perform other actions.
• Response Modification: You can modify the response object, such as adding custom response headers, changing the status code, or altering the response content, using resource filters.
• Request Preprocessing: Resource filters can perform actions at the beginning of the request pipeline, such as setting request-specific variables or performing other pre-processing tasks.
• Global Logging: You can use resource filters for global logging to log information about incoming requests, response times, or other metrics that apply to the entire application.

Example
Let's create a simple resource filter that adds a custom response header to every response in your ASP.NET Core application. In this example, we'll add a "X-Custom-Header" to the response.

Create a custom resource filter.
using Microsoft.AspNetCore.Mvc.Filters;

public class AddCustomHeaderResourceFilter : IResourceFilter
{
public void OnResourceExecuting(ResourceExecutingContext context)
{
    // Code to execute before the action
    context.HttpContext.Response.Headers.Add("X-Custom-Header", "MyCustomValue");
}

public void OnResourceExecuted(ResourceExecutedContext context)
{
    // Code to execute after the action
}
}

You can do this in the ConfigureServices method.
services.AddMvc(options =>
{
options.Filters.Add<AddCustomHeaderResourceFilter>();
});

Now, this resource filter will be executed for every request in your ASP.NET Core application, and it will add the "X-Custom-Header" to the response headers.

Resource filters are a powerful way to perform global actions that apply to all requests and responses in your application, making them a valuable tool for tasks like global exception handling, response modification, and request preprocessing.

Action Filter
Action Filters in ASP.NET Core are attributes that allow you to add logic that runs before and after the execution of individual action methods in your controllers. These filters are used to perform tasks such as logging, input validation, modifying the action result, and more.

Example
Let's create a simple Action Filter to log the start and end of an action method.

Create a custom Action Filter.
using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.Extensions.Logging;

public class LogActionFilter : IActionFilter
{
private readonly ILogger<LogActionFilter> _logger;

public LogActionFilter(ILogger<LogActionFilter> logger)
{
    _logger = logger;
}

public void OnActionExecuting(ActionExecutingContext context)
{
    // This method runs before the action method
    _logger.LogInformation($"Action '{context.ActionDescriptor.DisplayName}' is starting.");
}

public void OnActionExecuted(ActionExecutedContext context)
{
    // This method runs after the action method
    _logger.LogInformation($"Action '{context.ActionDescriptor.DisplayName}' has completed.");
}
}

You can do this in the ConfigureServices method.
services.AddMvc(options =>
{
options.Filters.Add<LogActionFilter>();
});

Apply the Action Filter to a controller action method.
[ServiceFilter(typeof(LogActionFilter))] // Apply the filter to this action method
public IActionResult MyAction()
{
// Your action method logic
}

Now, whenever you call the MyAction method, the LogActionFilter will log the start and end of the action, providing you with a simple way to monitor the execution of your action methods.

Result Filter
Result Filters in ASP.NET Core are a type of action filter that executes code after an action method has been executed but before the result is processed and sent to the client. These filters are useful for modifying the response or result, adding custom headers, or performing actions related to the response before it is returned to the client.

Example
Let's create a simple Result Filter to add a custom header to the response.

Create a custom Result Filter.
using Microsoft.AspNetCore.Mvc.Filters;

public class AddCustomHeaderResultFilter : IResultFilter
{
public void OnResultExecuting(ResultExecutingContext context)
{
    // This method runs before the result is executed
    context.HttpContext.Response.Headers.Add("X-Custom-Header", "MyCustomValue");
}

public void OnResultExecuted(ResultExecutedContext context)
{
    // This method runs after the result is executed
}
}

You can do this in the ConfigureServices method.
services.AddMvc(options =>
{
options.Filters.Add<AddCustomHeaderResultFilter>();
});

Apply the Result Filter to a controller action method.
[ServiceFilter(typeof(AddCustomHeaderResultFilter))] // Apply the filter to this action method
public IActionResult MyAction()
{
// Your action method logic
}

When you call the MyAction method, the AddCustomHeaderResultFilter will add the "X-Custom-Header" to the response headers before it's sent to the client. This can be useful for scenarios where you want to add custom response headers, set response content types, or perform other response-related actions.

Exception Filter
Exception Filters in ASP.NET Core are a type of action filter that are specifically designed to handle exceptions that occur during the execution of an action method. These filters allow you to define custom logic to gracefully handle and respond to exceptions, providing a way to centralize error handling and improve the user experience.

How Exception Filters Work?
Exception filters are executed when an unhandled exception is thrown during the execution of an action method. They intercept the exception before it propagates up the call stack and provide an opportunity to perform custom error handling.
Use Cases for Exception Filters

Custom Error Pages: Exception filters can redirect the user to custom error pages, displaying user-friendly error messages instead of the default error page.
Logging and Reporting: You can use exception filters to log exceptions, making it easier to identify and fix issues. You can also report exceptions to external systems for further analysis.
Graceful Degradation: In cases where an exception occurs but the application can still function to some extent, an exception filter can handle the error and return a partial or degraded response instead of a complete failure.

Example
Let's create a simple Exception Filter to log and handle exceptions.

Create a custom Exception Filter.
using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.Extensions.Logging;

public class CustomExceptionFilter : IExceptionFilter
{
private readonly ILogger<CustomExceptionFilter> _logger;

public CustomExceptionFilter(ILogger<CustomExceptionFilter> logger)
{
    _logger = logger;
}

public void OnException(ExceptionContext context)
{
    // Log the exception
    _logger.LogError($"An exception occurred: {context.Exception.Message}");

    // Handle the exception
    context.Result = new ViewResult { ViewName = "Error" };
    context.ExceptionHandled = true;
}
}

You can do this in the ConfigureServices method.
services.AddMvc(options =>
{
options.Filters.Add<CustomExceptionFilter>();
});

Apply the Exception Filter to a controller action method.
[ServiceFilter(typeof(CustomExceptionFilter))] // Apply the filter to this action method
public IActionResult MyAction()
{
// Your action method logic
}

If an unhandled exception occurs in the MyAction method, the CustomExceptionFilter will log the error and redirect the user to a custom error page.

Real-World Use Cases
Action filters are incredibly versatile and can be applied to a wide range of scenarios. Here are some real-world use cases for action filters in ASP.NET Core.

• Logging: You can create an action filter that logs information about the execution of action methods, helping with debugging and monitoring.
• Validation: Implement input validation checks before an action method is executed to ensure that the input data is valid.
• Caching: Use action filters to cache the results of action methods to improve performance and reduce database or API calls.
• Security: Implement security checks and authorization logic using action filters to restrict access to certain action methods based on user roles and permissions.
• Exception Handling: Create custom exception filters to handle and log exceptions in a consistent and user-friendly manner.

Optimization of performance is an important part of software development. As developers, we frequently attempt to write code that is efficient and speedy. However, precisely assessing code performance can be difficult. This is where BenchmarkDotNet, a powerful.NET benchmarking library, comes in. In this post, we'll look at the capabilities of BenchmarkDotNet and show you how to use it to test your.NET programs.

What exactly is BenchmarkDotNet?
BenchmarkDotNet is an open-source.NET benchmarking library. It enables developers to create, execute, and evaluate benchmarks in order to assess the performance of their programs. BenchmarkDotNet is a vital tool for optimizing.NET applications since it provides precise measurements, many run modes, and statistical analysis.

Starting Over
Before we begin benchmarking, please confirm that BenchmarkDotNet is installed in your project. You may install it with the following command in the NuGet Package Manager Console:
dotnet add package BenchmarkDotNet

Creating Your First BenchmarkLet's create a simple benchmark to compare the performance of two different implementations of a function. Consider the following example where we want to find the factorial of a number. Now you create the ConsoleApp.

Create a Class name FactorialCalculator

public class FactorialCalculator
{
    public int CalculateRecursive(int n)
    {
        if (n == 0 || n == 1)
        {
            return 1;
        }
        return n * CalculateRecursive(n - 1);
    }

    public int CalculateIterative(int n)
    {
        int result = 1;
        for (int i = 1; i <= n; i++)
        {
            result *= i;
        }
        return result;
    }
}

Let's use BenchmarkDotNet to create benchmarks for these methods and measure their performance.
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using ConsoleApp2;

class Program
{
static void Main(string[] args)
{
    var summary = BenchmarkRunner.Run<FactorialBenchmarks>();
}
}

public class FactorialBenchmarks
{
private readonly FactorialCalculator _calculator = new FactorialCalculator();

[Benchmark]
public void RecursiveBenchmark()
{
    _calculator.CalculateRecursive(10);
}

[Benchmark]
public void IterativeBenchmark()
{
    _calculator.CalculateIterative(10);
}
}

In this example, we've created two benchmarks, RecursiveBenchmark and IterativeBenchmark, using the Benchmark attribute. The BenchmarkRunner.Run method triggers the benchmarks and generates a detailed report.
Running Benchmarks

Build in RELEASE Mode

• Open a terminal or command prompt.
• Navigate to the project directory using the cd command.

Run the following command to build the project in RELEASE mode:

Run Benchmarks
After building the project in RELEASE mode, you can run your benchmarks using the dotnet run command.
When building your project, it is crucial to do so in RELEASE mode in order to guarantee that the compiler applies optimizations. This will lead to more precise benchmark results. By following this suggestion, you can avoid receiving warning messages and anticipate dependable performance measurements for your benchmarks.
When you have run it then you see

It may take some time for the results to display after running the application.

It may take some time for the results to display after running the application.

• WorkloadPilot is the code you want to measure.
• OverheadWarmup and OverheadActual account for the time and resources consumed by BenchmarkDotNet itself.
• WorkloadWarmup measures the time it takes for your code to stabilize during the warm-up phase.
• WorkloadActual measures the actual performance of your code once it has reached a stable state.

Result Summary Section

The two methods we're evaluating are listed in the overview section, along with their performance metrics. The mean measure, which is the average time it takes to run each procedure, is the most essential metric.

Conclusion
BenchmarkDotNet streamlines the process of measuring performance in.NET applications. It enables developers to find bottlenecks and improve their code effectively by delivering reliable data and statistical analysis. Consider incorporating BenchmarkDotNet into your workflow as you continue to develop high-performance applications to guarantee your code runs as efficiently as possible.

A circuit breaker is a software development design pattern intended to improve the resilience and fault tolerance of programs that connect with external services or resources. It takes its name from its electrical counterpart, which is intended to safeguard an electrical circuit from harm caused by high current. A circuit breaker in software performs a similar function by preventing the application from continually attempting to call a malfunctioning service or resource, which might lead to performance deterioration and other issues.

Circuit Breaker Diagram
Here's a breakdown of the circuit breaker pattern.

1. Normal Operation (Closed State)

    When the circuit breaker is closed, requests can travel through normally.
    It tracks the success and failure of these queries during this condition.
    When a particular number of failures are reached, the circuit breaker switches to the open position.

2. Unavailable State (Service)

    When the circuit breaker is open, it prevents requests from reaching the failing service or resource.
    This condition is activated when a preset number of failures is exceeded.
    No requests are sent to the service/resource while it is open, which might minimize the stress on the resource.
    The circuit breaker verifies if the service/resource has recovered on a regular basis by allowing a restricted number of test requests to get through.

3. Half-Open State (Service Availability Testing)

    After a predetermined period of time, the circuit breaker switches to the half-open position.
    In this condition, only a limited number of test requests can be sent to the service/resource to see if it has recovered.
    If these test requests are successful, the circuit breaker returns to the closed position.
    If the test requests continue to fail, the circuit breaker returns to the open position, protecting the system from additional failures.

Important Concepts

• Circuit breakers have thresholds that determine when they switch between states. The number of successive failures, the failure rate, or a combination of factors could be used to set these criteria.
• Timers: Timers regulate how long the circuit breaker stays in each state. For example, it may remain in the open state for a predetermined period of time before shifting to the half-open state.
• Monitoring and request tracking are required to determine the health of the service or resource and to determine when to open or close the circuit.
• Fallback Mechanism: While in the open state, apps can design fallback mechanisms to provide alternative functionality or smooth service degradation.
• Automated Recovery: When the service/resource appears to have recovered, circuit breakers automatically return to the closed state, decreasing the impact on the system.

By isolating problematic services or resources, the circuit breaker design helps to prevent cascading failures in distributed systems, enhances system stability, and provides a level of fault tolerance. It is a basic idea in the development of strong and resilient software systems.

Circuit Breaker Pattern in .Net Core
Let's implement the same in .Net Core using two different approaches.

• Approach 1 - Without using any specific Nuget package
• Approach 2 - Using Polly Nuget package

Common steps for both approaches( will also upload the solution with this article). I am using Visual Studio for mac but you can use Visual Studio code as well.

Create a new .NET Core API Project
Add a new interface for service and the concrete service class with HttpClient as a dependency
In the concrete service, add code to make an HttpRequest to a random api and get request. I am using an open source webapi for getting random jokes
Add a controller and call the above created service in it

Joke Interface
namespace CircuitBreaker
{
    public interface IJokeService
    {
        public Task<string> GetRandomJokes();
    }
}

Joke Service
namespace CircuitBreaker
{
    public class JokeService : IJokeService
    {
        private readonly HttpClient _httpClient;

        public JokeService(HttpClient httpClient)
        {
            _httpClient = httpClient;
        }

        public async Task<string> GetRandomJokes()
        {
            try
            {
                var request = new HttpRequestMessage
                {
                    Method = HttpMethod.Get,
                    RequestUri = new Uri("https://official-joke-api.appspot.com/random_joke")
                };
                var response = await _httpClient.SendAsync(request);
                response.EnsureSuccessStatusCode();

                var responseBody = await response.Content.ReadAsStringAsync();
                return responseBody;
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
    }
}

Joke Controller
using Microsoft.AspNetCore.Mvc;

namespace CircuitBreaker.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class JokeController : ControllerBase
    {
        public readonly IJokeService _jokeService;

        public JokeController(IJokeService jokeService)
        {
            _jokeService = jokeService;
        }

        [HttpGet(Name ="GetRandomeJokes")]
        public async Task<IActionResult> Get()
        {
            try
            {
                var response = await _jokeService.GetRandomJokes();
                return Ok(response);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
    }
}

Program.cs/StartUp.cs
public static void ConfigureService(IServiceCollection services)
{
    services.AddHttpClient<IJokeService, JokeService>();
}

Sample output
{"type":"general","setup":"What's brown and sticky?","punchline":"A stick.","id":271}

Now, the circuit breaker strategy usually allows an n number of failed tries before not-allowing any futher requests and breaking the circuite for some time. These n tries are with state, let me explain in more clarity.

Let's suppose the n count is 3 and 3 three different users tries to access the api one after the other(irrespective of the time difference between these requests) and if all three of these fails, then the 4th atempt should not even go through. The code should not further try to hit the other api untill a specifc time internal. Uptill this time interval, all requests attempts will just by-pass the api call and provide a message to end-user to try after some time. This can go in a loop if the other api issue is not resolved. This helps in making sure that the other service that we are calling is not overwhelmed with failing requests.

Let's try to implement this in Approach 1.

Create some static variables. We are creating them static as we want to persist the value of them between different calls. Please read comments for more understanding of each of it's use
//count of failed attempts that have been made
private static int attemptCount = 0;

//count of failed attempts allowed, post which the circiut will break
private static int maxAttemptCount = 3;

//flag to represent if the circuit is open or close
private static bool isCircuitOpen = false;

//field to keep a track of the utc time when the circuit was opened/broken
private static DateTime circuitOpenStartTime = DateTime.MinValue;

//the timestamp (in millisecond) for which the circuit should remain open and api call attempts should not be made
private static int circuitBreakerTimeSpanMilliseconds = 120000;

//method to start the circuit breaker
//if sets the isCircuitOpen to true and sets the time when the circuit was broken in utc
private void RecordCircuitBreakerStart()
{
    circuitOpenStartTime = DateTime.UtcNow;
    isCircuitOpen = true;
}

//method to end the circuit breaker
private void RecordCircuitBreakerEnd()
{
    circuitOpenStartTime = DateTime.MinValue;
    isCircuitOpen = false;
    attemptCount = 0;
}

//check if currently the circuit is broken or not
private void CheckIfCircuitBreakerTimeStampIsComplete()
{
    if(isCircuitOpen == true && circuitOpenStartTime.AddMilliseconds(circuitBreakerTimeSpanMilliseconds) < DateTime.UtcNow)
    {
        RecordCircuitBreakerEnd();
     }
}

Now, let's call the above method in our controller method
public async Task<string> GetRandomJokes()
{
    try
    {
        //check if the circuit was earlier open can can be closed now
        CheckIfCircuitBreakerTimeStampIsComplete();
        if (isCircuitOpen == false)
        {
            #region MakeAPICall
            var request = new HttpRequestMessage
            {
                Method = HttpMethod.Get,
                RequestUri = new Uri("https://official-joke-api.appspot.com/random_joke")
            };
            var response = await _httpClient.SendAsync(request);
            response.EnsureSuccessStatusCode();

            var responseBody = await response.Content.ReadAsStringAsync();
            return responseBody;

            #endregion
        }
        return "Service is not available. Please try after some time";
    }
    catch (Exception ex)
    {

        //in case of exception, if the max attempt of failure is not yet reached, then increase the counter
        if(isCircuitOpen == false && attemptCount < maxAttemptCount)
        {
            attemptCount++;
        }
        //if the count of max attempt if reached, then open the circuits and retuen message that the service is not available
        if(attemptCount == maxAttemptCount)
        {
            if (isCircuitOpen == false)
            {
                RecordCircuitBreakerStart();
            }
            return "Service is not reachable. Please try after some time";
        }
        return ex.Message;
    }
}

I agree with what you all must be thinking, the above approach is indeed messy and prone to more errors as we are managing multiple things at the same time. In order to make this code more readable and less error prone, we move to Approach 2

Approach 2 - In this we use an existing Nuget package, called Polly to achieve the same.

In the above code, add the nuget package Polly as in the screenshot below:

Add another nuget package - Microsoft.Extensions.Http.Polly to the solution
These packages enable us to define different policies to come into effect in case of an error. One of such policy is CircuitBreaker. Other policies to look at are RetryPolicy and WaitAndRetryPolicy.

For this, we will be adding another interface method and another service method called GetRandomJokesV2().

namespace CircuitBreaker
{
    public interface IJokeService
    {
        public Task<string> GetRandomJokes();
        public Task<string> GetRandomJokesV2();
    }
}

public async Task<string> GetRandomJokesV2()
{

    try
    {
            var request = new HttpRequestMessage
            {
                Method = HttpMethod.Get,
                RequestUri = new Uri("https://official-joke-api.appspot.com/random_joke")
            };
            var response = await _httpClient.SendAsync(request);
            response.EnsureSuccessStatusCode();

            var responseBody = await response.Content.ReadAsStringAsync();
            return responseBody;
    }

    catch (BrokenCircuitException ex)
    {

        return $"Request failed due to opened circuit: {ex.Message}";
    }
    catch (HttpRequestException httpEx)
    {
        return $"Request failed. StatusCode={httpEx.StatusCode} Message={httpEx.Message}";
    }
}

We then updated the ConfigureService method in Program.cs to add this policy. See code below:

public static void ConfigureService(IServiceCollection services)
{
    services.AddHttpClient<IJokeService, JokeService>(client =>
    {
        client.BaseAddress = new Uri("https://official-joke-api.appspot.com/random_joke");
    }).AddTransientHttpErrorPolicy(policy => policy.CircuitBreakerAsync(3, TimeSpan.FromMilliseconds(120000)));
}

In the above code, we are telling the middleware that in case this api call fails after 3 attempts, then by-pass all future api calls for 120000 miliseconds(2 mins). Post that there will be attempts to hit the api.

The way we call it in the Controller or servide does not change much
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;

// For more information on enabling MVC for empty projects, visit https://go.microsoft.com/fwlink/?LinkID=397860

namespace CircuitBreaker.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class JokeV2Controller : ControllerBase
    {
        public readonly IJokeService _jokeService;

        public JokeV2Controller(IJokeService jokeService)
        {
            _jokeService = jokeService;
        }

        [HttpGet(Name = "GetRandomeJokesV2")]
        public async Task<IActionResult> Get()
        {
            try
            {
                var response = await _jokeService.GetRandomJokesV2();
                return Ok(response);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
    }
}

We can clearly see that the Approach 2 is a more advisable and enterprise approach which makes our code more readable and less prone to errors. We can also make all the policies inside another folders as classes and inject them wherever required. This will make our code more abstract.

Please let me know your thoughts on this. I am also attaching my solutions in this post.

Middleware is the unsung hero of ASP.NET Core apps. It is critical in processing HTTP requests and responses, allowing developers to shape the flow of data in a flexible and orderly manner. In this post, we will take a tour through the diverse terrain of designing middleware in.NET Core, demonstrating real-time examples for a better understanding.

The Middleware Landscape
Middleware in ASP.NET Core serves as a link between the web server and your application. It has the ability to intercept, modify, or even short-circuit the request-response flow. Understanding the various methods for creating middleware is vital for developing powerful web applications.

1. Inline Middleware
The simplest way to create middleware is by defining it inline within the Configure method of your Startup class. Let's consider an example where we want to log incoming requests:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.Use(async (context, next) =>
    {
        // Log the incoming request
        LogRequest(context.Request);
        await next.Invoke();
        // Log the response
        LogResponse(context.Response);
    });
    // Other middleware and app configuration
}

This inline middleware logs both the request and response details for every incoming request.

2. Class-based Middleware
For more organized and reusable middleware, you can create custom middleware classes. Here's an example of a custom middleware class that performs authentication:

public class AuthenticationMiddleware
{
    private readonly RequestDelegate _next;
    public AuthenticationMiddleware(RequestDelegate next)
    {
        _next = next;
    }
    public async Task InvokeAsync(HttpContext context)
    {
        // Perform authentication logic
        if (!context.User.Identity.IsAuthenticated)
        {
            context.Response.StatusCode = 401;
            return;
        }
        await _next(context);
    }
}

In the Startup class, register and use this middleware:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseMiddleware<AuthenticationMiddleware>();
    // Other middleware and app configuration
}

3. Middleware Extension Methods
To keep your Startup class clean, you can create extension methods for middleware. Continuing with the authentication example, here's how you can create an extension method:
public static class AuthenticationMiddlewareExtensions
{
    public static IApplicationBuilder UseAuthenticationMiddleware(this IApplicationBuilder app)
    {
        return app.UseMiddleware<AuthenticationMiddleware>();
    }
}

Now, in your Startup class, using this extension method is as simple as:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseAuthenticationMiddleware();
    // Other middleware and app configuration
}

4. Middleware Pipeline Ordering
Order matters in middleware. The sequence in which you add middleware components to the pipeline affects their execution. For instance, if you have middleware that handles error responses, it should be placed after other middleware to catch exceptions.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseExceptionHandler("/Home/Error");  // Error handling middleware
    // Other middleware and app configuration
}

Summary
Middleware is a fundamental part of building robust ASP.NET Core applications. Knowing the various ways to create middleware, from inline methods to class-based and extension methods, empowers you to structure your application's request-response pipeline effectively. By understanding the order of execution in the middleware pipeline, you can ensure that each component plays its role at the right moment. As you continue your journey in ASP.NET Core development, mastering middleware creation will be a valuable skill in your toolkit, enabling you to craft efficient and resilient web applications.