When working on large-scale applications in C#, partial classes provide a convenient way to split a class across multiple files. This feature is especially useful in team-based projects or auto-generated code scenarios. In this article, we'll explore the benefits of partial classes, when to use them, and how to implement them effectively.

Join WhatsApp Group of .NET Developers

What Are Partial Classes?

A partial class in C# allows a single class, interface, or struct to be divided into multiple physical files. While the class appears as a single entity in memory during runtime, it is split into several files for better manageability during development.

When and Why to Use Partial Classes

Partial classes are commonly used in scenarios where the code base is large, and maintaining a single file would make the code unwieldy. They offer several key benefits:

1. Code Organization:

When a class becomes too large or contains different sets of functionalities, partial classes enable the logical division of code into smaller files. This promotes clean separation of concerns.

2. Team Collaboration:

In large projects, partial classes allow multiple developers to work on the same class without causing conflicts. Each developer can focus on different aspects of the class, such as methods or properties, in separate files.

3. Auto-Generated Code:

Partial classes are extensively used in auto-generated code scenarios, such as in Windows Forms, WPF, or ASP.NET. The auto-generated code resides in one file, while custom logic resides in another, preventing the loss of custom code when regenerating the file.

How to Implement Partial Classes

Using partial classes is simple. You just need to use the partial keyword when defining a class in multiple files. Here's an example:

File 1: Car_Part1.cs

public partial class Car
{
    public string Make { get; set; }
    public string Model { get; set; }

    public void DisplayCarInfo()
    {
        Console.WriteLine($"Make: {Make}, Model: {Model}");
    }
}

File 2: Car_Part2.cs

public partial class Car
{
    public int Year { get; set; }
    public string Color { get; set; }

    public void DisplayColor()
    {
        Console.WriteLine($"Color: {Color}");
    }
}

In this example, the Car class is split across two files. When compiled, both parts will be combined into a single class with all properties and methods accessible as if they were defined in one file.

When Not to Use Partial Classes

While partial classes provide flexibility and improve code organization, there are scenarios where using them may not be ideal:

• Excessive Use: Overusing partial classes can lead to scattered code, making it harder to track where specific functionality resides.

• Readability Issues: Splitting related functionality across multiple files can reduce readability, especially in smaller projects where the entire class can easily fit into a single file.

Conclusion

Partial classes offer a way to manage large codebases more effectively, streamline team collaboration, and keep auto-generated code separate from custom logic. However, they should be used with care to avoid reducing code clarity.

By understanding when and how to use partial classes, developers can maintain cleaner, more organized projects, especially as their applications scale.

Async/await in .NET simplifies asynchronous programming, allowing developers to write non-blocking code. However, several misconceptions surround its use. In this article, we'll explore three common myths about async/await and clarify how it works with code examples.

Join WhatsApp Group of .NET Developers

Myth 1: Async/await Creates New Threads

Some believe that using async/await automatically spawns new threads for every operation.

Reality: Async/await doesn’t create new threads directly. Instead, it reuses threads from the thread pool and runs tasks without blocking the main thread.

public async Task PerformAsyncOperation()
{
    // This simulates an I/O-bound operation like an HTTP request
    await Task.Delay(2000); // Simulates waiting for a response

    Console.WriteLine("Operation complete.");
}

In the above code, Task.Delay(2000) doesn’t block the calling thread for 2 seconds. Instead, it schedules the continuation after the delay, releasing the thread to handle other tasks.

Key Insight: Async/await enables efficient use of threads by reusing existing ones from the thread pool, especially for I/O-bound operations.

Myth 2: Async/await Automatically Improves Performance

There is a misconception that using async/await will automatically speed up the execution of code.

Reality: While async/await improves responsiveness, particularly with I/O-bound tasks, it doesn’t necessarily increase performance for CPU-bound tasks.

public async Task ProcessDataAsync()
{
    // Simulates an I/O-bound operation like reading from a file
    await Task.Delay(1000);

    // Simulates CPU-bound processing
    for (int i = 0; i < 1000000; i++)
    {
        // Intensive computation
        var result = Math.Sqrt(i);
    }

    Console.WriteLine("Data processing complete.");
}

In the example, the Task.Delay(1000) prevents the thread from being blocked while waiting for I/O. However, the CPU-bound loop that follows doesn't benefit from async/await and takes up processing power as usual.

Key Insight: Async/await improves responsiveness during I/O-bound tasks but doesn't offer significant performance boosts for CPU-bound operations.

Conclusion

By understanding and debunking these myths, you can use async/await effectively in your .NET projects:

1. Async doesn’t create new threads or guarantee faster execution—it improves responsiveness for I/O-bound tasks.

2. Async methods are best suited for non-blocking I/O operations, not CPU-bound tasks.

When working with collections in C#, the foreach statement provides an easy way to iterate over elements. To make sure a custom collection type works seamlessly with foreach, developers need to understand the mechanics behind it. In this article, we'll explore how the foreach loop functions, the rules it follows, and how to implement it in your custom types.

Join WhatsApp Group of .NET Developers

foreach Internals

In C#, the foreach loop can iterate over any collection or type that follows specific rules. These rules define how the loop retrieves each element one by one.

How foreach Works Internally:

1. GetEnumerator Method:
   The collection must have a method called GetEnumerator that returns an object responsible for the iteration. This object is called the enumerator.

2. MoveNext Method:
   The enumerator object needs to provide a MoveNext method. This method advances the enumerator to the next element in the collection and returns a bool:

   • true if there are more elements.

   • false if the end of the collection has been reached.

3. Current Property:
   The enumerator also needs a property named Current, which provides the current item in the collection. This property is read-only, meaning it allows access to the item but does not permit modification.

Even though the .NET framework provides IEnumerable and IEnumerable<T> interfaces to formalize these rules, the compiler doesn't require the collection to implement them as long as the necessary methods and properties are in place.

How the Compiler Transforms foreach into Code

When you write a foreach loop, the compiler translates it into a series of method calls under the hood. Here’s a simple example:

foreach (string name in names)
{
    Console.WriteLine($"{name} has {name.Length} characters.");
}

The above code gets transformed into something like this:

IEnumerator e = names.GetEnumerator();
while (e.MoveNext())
{
    string name = (string)e.Current; // Current is read-only!
    Console.WriteLine($"{name} has {name.Length} characters.");
}

As you can see, the compiler:

• Calls the GetEnumerator method on the collection.

• Uses the MoveNext method to loop through each element.

• Accesses the Current property to get the value of the current element in each iteration.

This process ensures that the foreach statement works seamlessly with any collection that adheres to the rules of enumeration.

Why You Can’t Modify Current in foreach

One important limitation of the foreach loop is that the variable representing the current item is read-only. This is because the Current property, which provides access to the current element, is designed to be immutable. The iterator pattern ensures that the collection remains unchanged while it's being traversed, maintaining the integrity of the data.

Implementing IEnumerable for Custom Types

While the compiler doesn't enforce the use of IEnumerable, implementing it is a good practice. Doing so makes your custom collection more versatile and compatible with various LINQ methods and other .NET libraries. Here's a simple implementation of IEnumerable<T> in a custom collection:

public class MyCollection<T> : IEnumerable<T>
{
    private T[] items;

    public MyCollection(T[] items)
    {
        this.items = items;
    }

    public IEnumerator<T> GetEnumerator()
    {
        for (int i = 0; i < items.Length; i++)
        {
            yield return items[i];
        }
    }

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

By implementing IEnumerable<T>, your collection can now be used in a foreach loop and benefit from the many tools in the .NET ecosystem.

Conclusion

Understanding how foreach works under the hood helps you implement custom collection types that are compatible with C#'s iteration features. Whether you’re working with built-in types or building your own, adhering to the rules of the iterator pattern ensures smooth, efficient looping with the foreach statement.

If you're working on scalable, flexible systems or need type safety with iteration, consider implementing the IEnumerable interface in your custom collections to enhance compatibility and usability in your projects.

Authentication is a fundamental part of any web application. Two of the most common methods for handling user authentication are JWT (JSON Web Token) and Session Cookies. While both methods serve the same purpose, they operate in distinct ways, each with its own advantages and disadvantages. In this article, we'll explore how each of these mechanisms works, their pros and cons, and when to use one over the other.

Join WhatsApp Group of .NET Developers

JWT Authentication

In JWT-based authentication, the server generates a token, which the client stores and sends back with each request. Unlike session-based methods, JWT authentication is stateless. This means that once a JWT is issued, the server doesn’t need to maintain any record of it, making it highly scalable.

How JWT Authentication Works:

1. Token Creation: Upon user authentication, the server generates a JWT containing the user's information.

2. Token Storage: This JWT is then sent back to the client, typically stored in local storage or an HTTP-only cookie for security.

3. Token Presentation: The client includes this JWT in the HTTP Authorization header for all subsequent requests to the server.

4. Token Validation: The server validates the JWT on each request. If the token is valid, the user is granted access.

   ---

Advantages of JWT:

• Scalability: Being stateless, JWTs are perfect for distributed systems where keeping track of session data across multiple servers is complex.

• Flexibility: JWTs can be used across different domains and applications, making them ideal for microservices architectures.

• Security: Proper implementation of JWT with features like encryption and signing can ensure secure handling of user authentication.

  ---

Session-Based Authentication

Unlike JWT, session-based authentication is stateful. In this method, the server generates and stores session data for the user on the server-side. The client holds only a session identifier, usually stored as a cookie.

How Session-Based Authentication Works:

1. Session Creation: The server verifies the user's credentials and creates a session record with details such as the user ID, session start time, expiry, and possibly other metadata like IP address and user agent.

2. Session Identifier: The server then sends a session identifier to the client, stored as a cookie.

3. Session Validation: For each subsequent request, the client sends the session identifier. The server queries its stored session records to validate the session.

4. Access Control: If the session is valid, the user is granted access to the requested resource.

   ---

Advantages of Session-Based Authentication:

• Simplicity: With all session data stored on the server, it’s straightforward to manage user sessions centrally.

• Revocation Efficiency: Sessions can be revoked or invalidated on the server instantly, ensuring that the user’s session is up to date and secure.

  ---

Choosing Between JWT and Session Cookies

When to Use JWT:

• Scalability Needs: JWTs are ideal for large-scale applications or distributed systems where maintaining session data on the server side becomes challenging.

• Cross-Domain Flexibility: If your application spans multiple domains or services, JWT offers flexibility without the complexity of sharing session state between servers.

  ---

When to Use Session Cookies:

• Simplicity and Security: For applications where simplicity is paramount and a centralized control of user sessions is required, session cookies provide a reliable and easy-to-manage solution.

• Immediate Revocation: If you need to revoke access instantly (e.g., for sensitive data access), sessions stored on the server offer greater control.

  ---

Conclusion

Both JWT and session-based authentication provide effective ways to handle user authentication, but each has its specific use cases. JWT is preferred for stateless, scalable systems where flexibility across domains is required, while session-based authentication is simpler and allows for more immediate control over user sessions.

Choosing the right method depends on your application’s needs. Consider your system’s scalability requirements, security concerns, and the complexity of session management when making your decision.

Concurrency control is a critical aspect of application development, especially when dealing with multi-user environments. In Entity Framework (EF) Core, managing concurrency becomes essential to ensure data consistency across transactions. In this article, we will dive into two primary concurrency management strategies—Optimistic Locking and Pessimistic Locking—explaining how each works, when to use them, and how they are implemented in EF Core.

Join WhatsApp Group of .NET Developers

What is Optimistic Locking?

Optimistic Locking assumes that most operations will not conflict, so no locks are held on the data until it's time to save changes. This strategy works well in high-concurrency environments where conflicts are rare, allowing transactions to proceed without waiting on locks.

How Optimistic Locking Works

In EF Core, optimistic locking is usually achieved by adding a concurrency token to the entity, such as a version or timestamp field. When an update is made, EF Core checks this token to ensure no other transaction has modified the data since it was last read. If a conflict is detected, a DbUpdateConcurrencyException is thrown, indicating that the update cannot proceed.

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    
    // Optimistic concurrency token
    [Timestamp]
    public byte[] RowVersion { get; set; }
}

In this example, the RowVersion property acts as the concurrency token. When an update occurs, EF Core checks this property to detect changes made by other transactions.

Here's how you might handle optimistic locking in practice:

try
{
    var product = dbContext.Products.Find(productId);
    product.Price = newPrice;
    
    // Save changes with optimistic concurrency check
    dbContext.SaveChanges();
}
catch (DbUpdateConcurrencyException)
{
    // Handle the concurrency conflict
    Console.WriteLine("Concurrency conflict detected!");
}

Ideal Scenarios for Optimistic Locking

Optimistic locking is best suited for scenarios where:

• Conflicts are rare.

• High concurrency is expected, and performance is a priority.

• The application can tolerate occasional retry logic in case of conflicts.

What is Pessimistic Locking?

Pessimistic Locking takes a more cautious approach, assuming that conflicts are likely. When data is read, it is locked immediately, preventing other transactions from modifying it until the lock is released. This approach ensures strict data consistency but can lead to performance bottlenecks in high-concurrency scenarios.

How Pessimistic Locking Works

In EF Core, pessimistic locking is typically implemented using raw SQL queries with locking hints like UPDLOCK and ROWLOCK. This ensures that the data is locked for the duration of the transaction, preventing other operations from reading or writing to it.

using (var transaction = dbContext.Database.BeginTransaction(System.Data.IsolationLevel.Serializable))

using (var transaction = dbContext.Database.BeginTransaction(System.Data.IsolationLevel.Serializable))
{
    // Execute raw SQL with pessimistic locking
    var product = dbContext.Products
        .FromSqlRaw("SELECT * FROM Products WITH (UPDLOCK, ROWLOCK) WHERE Id = {0}", productId)
        .SingleOrDefault();
    
    // Modify the product
    product.Price = newPrice;
    
    // Save changes
    dbContext.SaveChanges();
    
    // Commit the transaction
    transaction.Commit();
}

In this example, the UPDLOCK and ROWLOCK hints are used to lock the selected row until the transaction is complete.

Ideal Scenarios for Pessimistic Locking

Pessimistic locking is most appropriate when:

• Data integrity is critical, and conflicts must be avoided at all costs.

• You can afford the performance overhead that comes with locking resources.

• Transactions are short-lived, reducing the risk of deadlocks.

Understanding Which Strategy to Use

The choice between optimistic and pessimistic locking depends on the specific requirements of your application. Optimistic locking is generally the preferred option when:

• You expect minimal conflicts between transactions.

• High performance and scalability are crucial.

On the other hand, pessimistic locking is better suited for situations where:

• Conflicts are frequent.

• Strict data integrity is essential, and conflicts must be prevented proactively.

Conclusion

In EF Core, both optimistic and pessimistic locking offer distinct advantages depending on your application's concurrency needs. By understanding the trade-offs between performance and data integrity, you can select the right locking strategy to ensure smooth and reliable operation, even in complex, multi-user environments.

Make sure to choose the right strategy based on your application's requirements. Optimistic locking is usually a better fit for systems with high concurrency and rare conflicts, while pessimistic locking is ideal for environments where conflicts are more common and data integrity is paramount.

In the world of C# development, especially when working with ASP.NET Core, managing configuration settings is a vital aspect of building robust and scalable applications. One of the key tools for handling these configurations is the appsettings.json file. This article will walk you through what appsettings.json is, how it works, and how to use it effectively across different environments.

Join WhatsApp Group of .NET Developer

What is appsettings.json?

appsettings.json is the primary configuration file used in ASP.NET Core applications. It serves as a centralized location for storing application settings such as connection strings, API keys, logging configurations, and more. By keeping these settings in a JSON file, you can easily manage and modify them without the need to recompile your application.

Here’s a basic example of what an appsettings.json file might look like:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

Understanding Environment-Specific Configuration

ASP.NET Core allows you to create environment-specific versions of the appsettings.json file, such as appsettings.Development.json, appsettings.Staging.json, or appsettings.Production.json. These environment-specific files override the settings in the base appsettings.json file, allowing you to tailor the configuration for different stages of deployment.

For example, during development, you might connect to a local database with different logging levels. Your appsettings.Development.json might look like this:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=devDb;User Id=devUser;Password=devPassword;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "Microsoft": "Information"
    }
  }
}

In contrast, your appsettings.Production.json could have a more secure connection string and less verbose logging:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=prodServer;Database=prodDb;User Id=prodUser;Password=prodPassword;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft": "Error"
    }
  }

}

How Configuration is Loaded

When your ASP.NET Core application starts, it first loads the appsettings.json file. Afterward, it loads the environment-specific file corresponding to the current environment, such as appsettings.Development.json. This process ensures that the application uses the appropriate settings for the environment in which it’s running.

Setting the Environment

The environment is determined by the ASPNETCORE_ENVIRONMENT variable, which can be set in various ways:

1. Environment Variables: Set this variable on your server or development machine to Development, Staging, or Production.

2. launchSettings.json: For local development, you can specify the environment in the launchSettings.json file under the profiles section:

{
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Conclusion

Effective management of configuration settings is crucial for developing applications that are both flexible and maintainable. By leveraging the appsettings.json file and its environment-specific variants, you can seamlessly transition your application through various stages of development, testing, and production. This approach not only simplifies configuration management but also reduces the risk of errors when deploying to different environments.

Including environment-specific settings ensures that your app behaves as expected, whether you’re debugging locally or running in a production environment. Make sure to take full advantage of this powerful feature to keep your applications well-organized and easily configurable.

When designing data structures in C#, understanding the differences between class, struct, and record is essential to making informed decisions. So in this article we will compare these data types and see the differences and use cases of classes, struct and record.

Join WhatsApp Group of .NET Developers

Class

Reference Type: Classes are reference types, meaning they store a reference to the data rather than the data itself.

Heap Allocation: Objects are allocated on the heap, and garbage collection is responsible for memory management.

Use When: You generally use classes for complex data structures, long-lived objects, or when the size exceeds 16 bytes.

Example:

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

Use the keyword class to create a class in C#. You can specify an access modifier (private, public, protected, internal), if required, for the class.

Struct

Value Type: Structs are value types, meaning they store the actual data directly.

Stack Allocation: Structs are typically allocated on the stack, which can lead to better performance for small, short-lived instances.

Use When: Opt for structs when the data structure is small, immutable, and logically represents a single value. Avoid structs if the data structure is large or mutable.

Example:

struct Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

Use the struct keyword to declare the struct (structure) in C#. You can use access modifiers, if required.

Records

Reference or Value Type: Records can be either reference types (record class) or value types (record struct).

Value Equality: Unlike classes, records emphasize value equality, meaning two records with the same data are considered equal.

Immutability: Records are immutable by default, making them ideal for scenarios where the data should not change after creation.

Use When: Use records for immutable data structures, especially when you want concise syntax, like in request and response DTOs.

Example:

public record Person( string Name, int Age );

When to Use Which

Use Class: For most scenarios, especially when dealing with complex objects or when the instance size exceeds 16 bytes.

Use Struct: For small, simple, and immutable data structures, particularly when performance is a concern.

Use Record: For immutable data with value equality, such as DTOs, or when you want the convenience of built-in methods for deconstruction and printing.

Conclusion:

In conclusion, choosing between classes, structs, and records in C# depends on your specific use case. Classes are best for complex and long-lived objects, structs for small, simple, and performance-critical data, and records for immutable data structures with value equality. Understanding these distinctions allows you to optimize your code for performance, maintainability, and clarity.

When building APIs in ASP.NET Core, understanding how to bind incoming data to your action parameters is crucial. So in this article we will see the difference between all these attributes.

Join WhatsApp Group of .NET Developers

[FromForm]

Use [FromForm] when you want to bind data submitted as part of a form, typically via `multipart/form-data` or `application/x-www-form-urlencoded`. This is often used when handling form submissions in web applications.

public IActionResult SubmitData([FromForm] MyFormModel model)

Example: Uploading a file with additional form data.

[FromBody]

[FromBody] is used to bind data from the body of the request, typically in JSON or XML format. This is common in API endpoints that accept complex objects or raw data.

public IActionResult CreateItem([FromBody] MyItemModel item)

Example: Posting JSON data to create a new resource.

[FromQuery]

[FromQuery] binds data from query string parameters in the URL. This is useful for filtering, sorting, or searching operations where data is passed via the query string.

public IActionResult GetItems([FromQuery] string filter)

Example: `GET /items?filter=active`

[FromRoute]

Use [FromRoute] when you want to bind data directly from the route parameters in the URL. This is often used for identifying resources.

public IActionResult GetItem([FromRoute] int id)

Example: `GET /items/123` where `123` is the ID of the item.

[FromHeader]

[FromHeader] allows you to bind data from HTTP headers. This is useful for scenarios where you need to pass metadata, such as authentication tokens or custom headers.

public IActionResult GetData([FromHeader(Name = "X-Custom-Header")] string headerValue)

Example: Passing an API key via a custom header like `X-API-Key`.

Why Does This Matter? 🤔

Choosing the right attribute helps make your API clear, predictable, and easy to use. It ensures that your application correctly interprets where data is coming from, making your code more maintainable and reducing the risk of bugs.

Dapper is an open-source object-relational mapping (ORM) library for .NET and .NET Core applications. The library allows developers quickly and easily access data from databases without the need to write tedious code. Dapper allows you to execute raw SQL queries, map the results to objects, and execute stored procedures. In this article we will see the implementation of generic dapper repository to call the store procedures.

Join WhatsApp Group of .NET Developers

Dapper Repository Interface

Place this interface inside domain layer or in application layer.

Connection Factory Interface

Place this interface inside domain layer or in application layer beside your dapper repository interface. This connection factory is responsible for creating the connection with database

Implementation of Connection Factory Interface

Place this implementation inside your infrastructure project or maybe create a separate persistence project inside infrastructure and put this there.

Implementation of Dapper Repository

Place this implementation inside your infrastructure project or maybe create a separate persistence project inside infrastructure and put this there.

Dependency Injection

The Options pattern uses classes to provide strongly typed access to groups of related settings and helps to satisfy Encapsulation and Separation of concerns principals .options also provide a mechanism to validate configuration data. So when working with options pattern it provide three interfaces to inject the configuration into your services. IOptions, IOptionsSnapshot, IOptinosMonitor, so in this article we will talk about the difference between these interfaces.

Join WhatsApp Group of .NET Developers

𝐈𝐎𝐩𝐭𝐢𝐨𝐧𝐬 𝐢𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞
The lifetime of the IOptions interface is Singleton, and you can register it in any service lifetime. It has one limitation: when you start your app, and after starting, you change something in your configuration, it will not pick up the new configuration.

𝐈𝐎𝐩𝐭𝐢𝐨𝐧𝐬𝐒𝐧𝐚𝐩𝐬𝐡𝐨𝐭 𝐢𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞
The lifetime of the IOptionsSnapshot interface is Scoped because it is scoped; therefore, you cannot use this in your Singleton services. It is useful in scenarios where options should be recomputed on every request.

𝐈𝐎𝐩𝐭𝐢𝐨𝐧𝐬𝐌𝐨𝐧𝐢𝐭𝐨𝐫 𝐢𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞
The lifetime of the IOptionsMonitor interface is Singleton, and you can register it in any service lifetime, just like the IOptions interface.
However, IOptionsMonitor can read the latest configuration from your app settings even after you start your app; this is the major difference between the IOptions and IOptionsMonitor interfaces. The name of the property that stores the config value is CurrentValue instead of Value.

Quick look at IOptions, IOptionsSnapshot, IOptinosMonitor

When working with data in C#, understanding how your queries are executed is crucial for writing efficient and predictable code. LINQ (Language Integrated Query) introduces two key concepts in this regard: deferred execution and immediate execution. So in this article we will talk about how deferred query execution and Immediate Query Execution works in LINQ, and the difference between the two.

Join WhatsApp Group of .NET Developers

Deferred Execution

In case of differed execution, a query is not executed at the point of its declaration. It is executed when the Query variable is iterated by using loop for, foreach etc.

Think of deferred execution like making a shopping list. You write down everything you need, but you don't physically grab anything from the shelves until you reach the checkout. Similarly, in LINQ, deferred execution defines the operations needed on your data but doesn't actually retrieve it until required. This is especially useful when working with large datasets or performing multiple operations on the same data source.

Coding Example

IEnumerable<int> numbers = Enumerable.Range(1, 100);

var filteredNumbers = numbers.Where(n => n % 2 == 0);

// Nothing is executed yet!

Console.WriteLine(filteredNumbers.Count()); // Now the query executes

Immediate Execution

In case of immediate execution, a query is executed at the point of its declaration. The query which returns a singleton value (single value or a set of values) like Average, Sum, Count, List etc. caused Immediate Execution.

You can force a query to execute immediately of by calling ToList, ToArray methods.

Think of immediate execution like going straight to the shelves and fetching all items on your list, even if you don't need them immediately. In LINQ, immediate execution forces the query to be evaluated right away, returning the result as a data structure like a list or array.

Coding Example

List<int> evenNumbers = numbers.Where(n => n % 2 == 0).ToList();

// The query and filtering are executed immediately

Console.WriteLine(evenNumbers[0]); // Accessing the first even number

Choosing the Right Approach: When to Go Which Way

Deciding between deferred and immediate execution depends on your specific use case:

• Use deferred execution for:

  • Large datasets where you only need parts of the data.

  • Performing multiple operations on the same data source.

  • Avoiding unnecessary processing overhead.

• Use immediate execution for:

  • When you need all the data upfront for further processing.

  • Modifying the query results with additional LINQ operations.

  • Debugging purposes to inspect the actual data returned.

SOLID is an acronym for the five principles made popular by Robert C. Martin (also known as Uncle Bob).

SOLID stands for:

• S - Single-responsibility Principle

• O - Open-closed Principle

• L - Liskov Substitution Principle

• I - Interface Segregation Principle

• D - Dependency Inversion Principle

Join WhatsApp Group of .NET Developers

Single-Responsibility Principle

A class should have one and only one reason to change, meaning that a class should have only one job.

This principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.

Open-Closed Principle

Objects or entities should be open for extension but closed for modification.

This principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.

Liskov Substitution Principle

If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.

This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.

Interface Segregation

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.

Dependency Inversion

High-level modules should not depend on low-level modules. Both should depend on the abstraction. Abstractions should not depend on details. Details should depend on abstractions.

High-level Module(or Class): Class that executes an action with a tool.

Low-level Module (or Class): The tool that is needed to execute the action

Abstraction: Represents an interface that connects the two Classes.

This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.

Conclusion

To sum it up, SOLID principles are like a rulebook for writing good code. They help make software easier to understand, modify, and fix. By sticking to these principles, developers can create programs that are less likely to have problems and are simpler to work with in the long run. It's all about making code that just makes sense and works well.

DRY, YAGNI, KISS are nothing but set of guidelines that help you write clean, readable and more maintainable code. These set of guidelines proven to work over the years. So in this article we will understand these principles but even before that we will first discuss why you should learn this principles at the first place.

Join WhatsApp Group of .NET Developers

Why you should learn these principles?

These principles are a set of guidelines that help you write better, robust, and clean code. Once, you start applying them, you’ll start seeing the results on the overall process of developing products. Here are some advantages which will be visible in your code -

• Robustness

• Efficiency

• Delivering high-quality software

• Flexible, Easy to refactor

DRY ( Don’t Repeat Yourself)

As the name suggest Don’t Repeat Yourself, This principle focuses on applying reusability and reducing repetition in code. If you are reusing your code you are reducing the repetition and you are producing less code, less code is better then more code.

The most common example of DRY is functions! A general rule is if you are writing the same logic twice, it’s time to refactor the logic to a function and reuse it!

YAGNI (You Aren't Gonna Need It)

This principle focuses that always implement things when you actually need them, never when you just foresee that you need them.

Even if you're super sure that you'll need a feature, later on, don't implement it now. Usually, it'll turn out either:

• you don't need it after all, or

• what you actually need is quite different from what you foresaw needing earlier.

This doesn't mean you should avoid building flexibility into your code. It means you shouldn't over engineer something based on what you think you might need later on.

Premature Optimization is the Root of All Evil

Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.

KISS (Keep It Simple Stupid)

The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

This principle literally means to keep your code as simple code as possible. The simpler the code, the easier it is to understand and maintain it.

Simple code has the following benefits:

• Less time to write

• Less chances of bugs

• easier to understand, debug and modify

Conclusion

In conclusion, implementing the engineering principles of DRY, YAGNI, and KISS in your applications enhances code quality and maintainability. These guidelines promote reusability, and simplicity, leading to efficient, high-quality software. By following these principles, developers can create cleaner, more resilient code and streamline the development process.

Well we all know that a dictionary in C# is a generic collection that can be used to store key/value pairs, where each key is unique within the dictionary, and it maps to a specific value. But when we come to know that concurrent dictionary is also a thing then most of us got confused between dictionary and concurrent dictionary. So in this article we will understand the difference between dictionary and concurrent dictionary, also we will talk about that in which scenario you should use standard dictionary and when you should use concurrent dictionary.

Join WhatsApp Group of .NET Developers

What is Dictionary?

A dictionary is essentially a generic collection of key-value pairs, where each key corresponds to a unique value. You can draw an analogy between a dictionary in programming and a real-world dictionary, where you look up a word (key) to find its definition (value).

The `Dictionary<TKey, TValue>` class in .NET allows you to define both the data type for keys (`TKey`) and the data type for values (`TValue`). For instance, you can create a dictionary with integers as keys and strings as values, denoted as `Dictionary<int, string>`. It provides a structured way to organize and retrieve data.

It's important to note that in a `Dictionary`, keys must be unique, ensuring that each key is associated with a single value. Additionally, keys should not be null for reference types. On the other hand, values can be null, especially if they are of a reference type.

What is Concurrent Dictionary?

A `ConcurrentDictionary` is a thread-safe collection of key-value pairs, providing a mechanism for multiple threads to access and modify the data concurrently while ensuring data integrity. This class is specifically designed to handle scenarios where multiple threads might simultaneously access, add, or modify entries in the dictionary.

The primary goal of the `ConcurrentDictionary<TKey, TValue>` class is to prevent race conditions, a common issue that arises when two or more threads attempt to access and modify shared data simultaneously. Race conditions can lead to unpredictable behavior, including data corruption, incorrect results, or exceptions.

What you should use Dictionary and when Concurrent Dictionary?

ConcurrentDictionary is primarily for use in an environment where you're updating the dictionary from multiple threads (or async tasks). You can use a standard Dictionary from as much code as you like if it's from a single thread.

If you look at the methods on a ConcurrentDictionary, you'll spot some interesting methods like TryAdd, TryGetValue, TryUpdate, and TryRemove.

For example, consider a typical pattern you might see for working with a normal Dictionary class.

if (!dictionary.ContainsKey(id))
    dictionary.Add(id, value);

This has an issue in that between the check for whether it contains a key and calling Add a different thread could call Add with that same id. When this thread calls Add, it'll throw an exception. The method TryAdd handles that for you and will return a true/false telling you whether it added it (or whether that key was already in the dictionary).

So unless you're working in a multi-threaded section of code, you probably can just use the standard Dictionary class. That being said, you could theoretically have locks to prevent concurrent access to a dictionary.

Real-World Use Case of a Dictionary: Based on My Experience

In a project I worked on, I stored unique device IDs from mobile devices in a standard dictionary. All API calls were asynchronous, and upon receiving a request, I checked whether the device ID existed in the standard dictionary. If it did, I approved the request; otherwise, I fetched the device ID from the database and stored it in the dictionary.

However, I encountered a wired issue where, at times, the mobile client would throw an ArgumentException stating "Item with the same key has already been added." To address this issue, I replaced the standard dictionary with a concurrent dictionary. This change resolved the problem, ensuring that concurrent access to the dictionary by multiple threads did not result in key conflicts or exceptions. The concurrent dictionary provided the necessary thread safety, preventing simultaneous additions or modifications to the dictionary from causing errors.

Concurrency and Parallelism are two concepts that are often used interchangeably but have distinct meanings and implications. So in this article we will understand the core of these concepts, also we will talk about advantages and key differences between concurrency and parallelism.

Join WhatsApp Group of .NET Developers

Understanding the Core Differences:

Concurrency: is a condition that exists when at least two tasks can start, run, and complete in overlapping time periods. Concurrency is the illusion of parallelism, it feels like parallel but actually it is not parallel. For example, multitasking on a single-core machine is a form of concurrency, where the processor switches between tasks at a very fast rate, creating the illusion of parallelism. Async/Await in C# is an example of concurrency.

Imagine a juggling act. You can only hold one ball at a time, but you can rapidly switch between them, creating the illusion of juggling multiple balls simultaneously. This is concurrency in action.

Parallelism: is a condition that arises when at least two tasks are executing simultaneously. It means that they are literally running at the same time.Task Parallel Library (TPL) in C# is an example of parallelism where you can pass your Tasks to this WhenAll method and those tasks run at the same time.

Imagine a real-life juggling act with multiple jugglers. Each juggler can handle multiple balls independently and simultaneously. This is parallelism in action.

Advantages:

Concurrency:

• In the context of WEB API’s concurrency increase the throughput of your API, which mean you can handle more requests. Like for example if one request come to you and now you hit the DB and your CPU is waiting for response from DB during that time you can handle other requests.

• In the context of UI Based Apps concurrency increase the responsiveness & interactivity of your application by allowing tasks to run in the background without blocking the user interface.

Parallelism:

• Improving the performance and efficiency of the application by utilizing the full potential of the hardware resources. Because now you are actually doing multiple things at the same time.

• It also reduce the latency in the response, for example if there are two tasks each take 5 seconds total 10 seconds to complete but now because they are running in parallel then instead of taking 10 seconds to complete both task will complete in total 5 seconds.

Key difference between concurrency and Parallelism:

Concurrency: mean utilizing your resources efficiently where two tasks can start run and complete at overlapping time. It is like one juggler juggling between balls.

Parallelism: mean actually doing multiple things at the same time where two task can start run and complete at same time. It is like two jugglers juggling the balls.

Concurrency aims to improve the responsiveness and interactivity of the application,

Parallelism: aims to improve the speed and efficiency of the application.

C# Examples of concurrency and parallelism:

Example of concurrency:

Example of parallelism:

Conclusion:

In conclusion, while concurrency and parallelism are often used interchangeably, they represent distinct concepts. Concurrency creates the illusion of simultaneous execution, beneficial for responsive user interfaces and multitasking. On the other hand, parallelism achieves true simultaneous execution, leveraging multiple cores or distributed systems for enhanced speed and efficiency. In C#, asynchronous programming exemplifies concurrency, while the Task Parallel Library showcases parallelism. The choice between these approaches depends on the specific goals, with concurrency enhancing user experience and parallelism maximizing computational power. Balancing these concepts ensures the development of robust and high-performing software systems.

A well designed application handle exceptions and errors gracefully and prevent application to crash. So in this article we will talk about 7 best practices to handle exceptions in a proper way.

Join WhatsApp Group of .NET Developers

1) Use a try/catch/finally block:

Use try/catch/finally to handle exceptions gracefully. The try block contains the code that might throw an exception, the catch block catches and handles the exception, and the finally block ensures that essential cleanup code is executed regardless of whether an exception occurred.

2) Handle common conditions without throwing exception:

Avoid using exceptions for flow control. Instead, handle common conditions with if statements or other appropriate checks. This improves performance and makes the code more readable, as exceptions should be reserved for exceptional and unexpected situations.

3) Design classes in a way that avoids exceptions:

Design classes with preventative methods or properties to mitigate the need for exceptions. For instance, a class can offer methods or properties, such as those found in the FileStream class, that allow users to check conditions before making a call that might lead to an exception. By incorporating such checks, classes can provide a more robust and error-resistant interface, minimizing reliance on exceptions for routine error handling scenarios.

4) Throw exceptions and log the details:

When throwing exceptions, log the details to aid in debugging. Store logs in a database, blog storage, or a file server for future analysis. This ensures that developers can investigate issues effectively and make informed improvements to the code.

5) Do not return sensitive information from exceptions to clients:

Avoid returning sensitive information in exception messages, as this can pose security risks. Instead, log detailed information for internal use, while providing generalized and user-friendly error messages to clients.

6) Implement global exception handling middleware:

Implement a global exception handling middleware in your .NET application to capture unhandled exceptions at a centralized level. This allows you to log the exceptions, notify administrators, and gracefully handle errors to provide a better user experience.

7) Throw Specific Exceptions:

Be specific when throwing exceptions. Instead of using generic exceptions, create custom exception classes that convey the nature of the problem. This aids in more precise error handling and makes it easier for developers to identify and address issues in the code.

Conclusion:

In conclusion, effective exception handling in .NET involves a combination of proactive design and thoughtful practices. Utilizing try/catch/finally blocks, handling common conditions without resorting to exceptions, and designing classes with preventative methods exemplify the importance of minimizing the reliance on exceptions for routine error scenarios. Additionally, logging exception details, implementing global exception handling middleware, and being specific in exception types contribute to a comprehensive approach for managing errors. By adhering to these principles, developers can enhance code robustness, maintainability, and user experience in .NET applications.

Why we need generic HttpClient Wrapper?

In .NET, making HTTP calls to 3rd-party APIs and services is an easy task with the help of HttpClient. However, when it comes to production, careful consideration is necessary before incorporating HttpClient directly into the codebase. Injecting HttpClient everywhere and making external API calls without proper management can be problematic. Therefore, it is advisable to use a generic wrapper to handle external API calls.

The Generic HttpClient Wrapper serves as a solution in such scenarios. This wrapper encapsulates all HttpClient logic, providing a clean and organized approach. By using this wrapper in our services, we can enhance the maintainability and readability of the codebase.

Join WhatsApp Group of .NET Developers

Let's dive into the code of HttpClient Wrapper and explore its usage:

Interface:

Class:

Let’s understand this code step by step:

Constructor: The class has a constructor that takes an instance of the HttpClient class. This is important for dependency injection, allowing the class to use an existing HttpClient instance.

GetAsync Method: This method performs an HTTP GET request. It takes a generic type for the expected response (TResponse) and an optional request object (TRequest). It constructs the URL with an optional query string based on the provided request. If the HTTP response indicates an error, it throws an exception. Otherwise, it reads the response body and deserializes it into the specified response type using Newtonsoft.Json.

PostAsync Method: Similar to GetAsync, this method performs an HTTP POST request. It takes a generic type for the expected response (TResponse), a request object (TRequest), and a content type. It serializes the request object into JSON and sends it as the request content. If the HTTP response indicates an error, it throws an exception. Otherwise, it reads the response body and deserializes it into the specified response type using Newtonsoft.Json.

Register your HttpClient Wrapper into your DI container.

Where to put your HttpClient Wrapper in your Clean Architecture?

HttpClient is external concern so put the Wrapper class in your infrastructure project & your Interface of HttpClient Wrapper will go into your application or domain layer.

Benefits:

• Reduced Code Duplication: Encapsulate common HTTP request logic in one place.

• Improved Maintainability: Easily modify and extend functionalities in a centralised class.

• Type Safety and Clarity: Generic methods ensure correct return types and promote consistent usage.

• Reusable Building Block: Leverage the wrapper across different parts of your application.

Additional Considerations:

• Logging: Implement logging for request/response details and improved debugging.

• Retries and Timeouts: Consider retrying failed requests and setting timeouts for better control.

• Authentication: Integrate authentication strategies for secure API access.

• Further Customisation: Expand functionalities like header manipulation, custom serialisation, and response validation.

Conclusion:

In summary, the Generic HttpClient Wrapper in .NET offers a systematic approach to manage HTTP calls, ensuring code cleanliness and maintainability, especially when interacting with external APIs. By encapsulating HttpClient logic, it minimises code duplication, promotes consistency, and facilitates easier modifications. Placing the wrapper in the infrastructure layer aligns with Clean Architecture principles. The wrapper's benefits, including reduced redundancy and enhanced re-usability, make it a valuable tool for developers, though attention to aspects like logging and customisation is crucial for optimal functionality. Overall, it serves as a key component for efficient and organised external API integration in applications.

Visit this github repo if you want to get the code

https://github.com/noumanbaloch/HttpClientWrapperDemo