Forem: Ben Witt

Transitive Dependency – Challenges and Approaches in .NET

Ben Witt — Wed, 12 Feb 2025 09:00:00 +0000

Imagine you are developing a .NET application that runs perfectly at first. Suddenly, however, unexpected runtime errors occur—even though your main project does not explicitly include any additional packages. How can this phenomenon be explained? Often, the cause is a transitive dependency: a library such as Entity Framework Core is silently included in your project via another NuGet package. In complex application scenarios, this issue can lead to version conflicts or even hard-to-diagnose runtime errors like the MissingMethodException. Without targeted management of these dependencies, the effort required for error resolution can become significant.

1. Basics and Problem Statement

1.1 Transitive References vs. Transitive Dependencies

Transitive References:

In a multi-layered solution structure, for example, Project A directly references Project B, which in turn uses Project C. In this way, Project A has an indirect (transitive) reference to Project C—even if it is not explicitly listed in the .csproj file.
Transitive Dependencies:

With external NuGet packages, the problem appears when they are brought in by a referenced package and do not show up in the main project’s .csproj file. For instance, if Project A uses a package (e.g., PackageX) that internally references EF Core in a specific version, then EF Core is included transitively—even though Project A never explicitly added it.

Isn’t it remarkable how quickly such subtle dependency chains can emerge in large projects without being noticed?

1.2 A Typical Scenario in .NET

In many .NET applications, Entity Framework Core (EF Core) is used as the data access library. Even if the main project does not directly reference EF Core, it can be silently included as a transitive dependency via another utility or data access package. Initially, everything seems to work smoothly—EF Core provides a stable API. However, when updating the .NET framework or integrating new features, version conflicts may occur that eventually lead to hard-to-diagnose runtime errors.

2. Detailed Solution Approaches

To prevent the unwanted propagation of packages, two main approaches are available: the targeted restriction of individual packages using PrivateAssets="all" or the complete deactivation of transitive project references with <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>. Both approaches are critically examined below.

2.1 `PrivateAssets="all"`

By adding the attribute PrivateAssets="all" in the PackageReference, you prevent the respective library from being passed on to other projects in the dependency hierarchy. This way, the package—and its transitive dependencies—remain available only within the current project.

Advantages:

Granularity: You decide on a package-by-package basis whether a dependency should be inherited.
Avoidance of Side Effects: Problematic libraries are not automatically transferred to subordinate projects.

Disadvantages:

Increased Configuration Effort: If another project needs the same library, it must be explicitly referenced again.

Example:

<ItemGroup>
  <PackageReference Include="SomeDataAccessPackage" Version="1.2.3" PrivateAssets="all" />
</ItemGroup>

Could it be that in complex environments the administrative effort for such package-specific configuration outweighs the benefits?

2.2 DisableTransitiveProjectReferences

With the global setting true in the .csproj file, you prevent the automatic propagation of all transitive project references. Every project must then explicitly list all the required packages.

Advantages:
• Increased Transparency: All dependencies are explicitly visible and controllable.
• Prevention of Unintended Inclusions: No “hidden” libraries are automatically added to the project.

Disadvantages:
• Higher Maintenance Effort: Explicitly listing all dependencies can create a significant administrative overhead, especially in larger projects.
• Risk of Omissions: Essential dependencies might accidentally be overlooked, leading to compile-time or runtime errors.

Example:


<PropertyGroup>
  <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>
</PropertyGroup>

Given the additional effort, is it really practical to explicitly declare all dependencies?

2.3 Comparison of Both Approaches

Criterion	PrivateAssets="all"	DisableTransitiveProjectReferences
Granularity	Package-specific control	Global deactivation – all dependencies must be explicitly referenced
Maintenance Effort	Requires individual adjustments per project	Higher maintenance effort due to separate management of all references
Clarity	Can lead to opaque dependency chains in complex structures	Clear separation, but increases the risk of overlooking essential packages
Flexibility	High flexibility in isolated control of individual packages	Strict control, but less adaptability

3. Practical Example: Abstraction and Interface Encapsulation

Consider a specific application: a .NET Standard library named Common encapsulates various helper methods and tools and internally includes a data access package that brings EF Core as a transitive dependency. In this case, it is advisable not to expose EF Core-specific classes in the public API; instead, these should be abstracted through interfaces.

Example Implementation:


// In Common
public interface IDataService
{
    IEnumerable<string> GetData();
}

internal class EfDataService : IDataService
{
    public IEnumerable<string> GetData()
    {
        // Internal use of EF Core
        return new List<string> { "Data from EF Core" };
    }
}

public static class DataServiceFactory
{
    public static IDataService CreateService()
    {
        return new EfDataService();
    }
}

Configuration in Common.csproj:


<ItemGroup>
  <PackageReference Include="SomeDataAccessPackage" Version="1.2.3" PrivateAssets="all" />
</ItemGroup>

This approach ensures that EF Core remains exclusively available internally—the main application only interacts with the interface without needing to know the underlying implementation.

4. Advanced Strategies and Alternative Approaches

In addition to the configuration options discussed above, other strategies can help minimize version conflicts and the issues of transitive dependencies:
• Binding Redirects:
Especially in older .NET Framework applications, binding redirects can help resolve conflicts between different versions of the same library.
• Modular Architectures:
Separating the application into clearly defined modules allows for targeted isolation of dependencies. This makes it easier to control unwanted side effects.

Should we not always question whether a focus solely on .csproj configurations in highly complex systems is truly the optimal solution?

5. Summary and Outlook

Transitive dependencies represent a serious issue in complex .NET projects. Seemingly insignificant libraries like EF Core can—when included via other NuGet packages—lead to significant version conflicts and runtime errors. Consistent separation of dependencies and the targeted use of measures such as PrivateAssets="all" or offer practical solutions. It is essential to weigh whether the administrative effort is justified by the benefits and how long-term maintainability can be ensured.

By using abstractions, explicit references, and additional measures such as binding redirects, developers can not only create a more stable codebase but also reduce ongoing maintenance efforts. Regularly reviewing dependency hierarchies using tools like dotnet list package --include-transitive or NDepend is indispensable.

Is it not ultimately the task of every developer to continually question whether the current architecture still meets the growing demands of modern applications?

I think so….!

Efficient Debugging and Precise Logging in C#: Using Caller Attributes

Ben Witt — Wed, 29 Jan 2025 17:01:53 +0000

How often do you wish, while debugging a complex application, to instantly see where in the code an error was triggered? Often, you are left with basic error messages that lack valuable context or exact code lines. This is where the C# attributes [CallerMemberName], [CallerFilePath], and [CallerLineNumber] come into play.

These attributes automatically provide information about the calling method’s name, the physical file path, and the line number in the source code when a method is called. This enables precise error tracking and logging, which is useful both during debugging and in production logging. Especially when troubleshooting large codebases, they prove to be indispensable tools for quick and targeted analysis.

Basics of the Attributes

The attributes [CallerMemberName], [CallerFilePath], and [CallerLineNumber] are applied directly to method parameters. The compiler automatically replaces the arguments with the corresponding values from the call context without any extra effort from the developer:
• [CallerMemberName] provides the name of the calling method.
• [CallerFilePath] gives the full path to the file where the method call is located.
• [CallerLineNumber] provides the line number of the call within that file.

The syntax is straightforward. A classic example:

public void LogInfo(
    string message, 
    [CallerMemberName] string memberName = "",
    [CallerFilePath] string filePath = "", 
    [CallerLineNumber] int lineNumber = 0)
{
    Console.WriteLine($"[{memberName}] {message} (File: {filePath}, Line: {lineNumber})");
}

Here, the parameters must have default values (e.g., = "" or = 0) so that the compiler can insert the values automatically. When you call the method without specifying these optional parameters, they are substituted automatically.

Example Method for Capturing Call Stack Information


public void ProcessData([CallerMemberName] string caller = "",
                        [CallerFilePath] string path = "",
                        [CallerLineNumber] int line = 0)
{
    Console.WriteLine($"Called by: {caller}, File: {path}, Line: {line}");
    // Further data processing code...
}

In this simple scenario, you can already gain initial insights into the call context and source code position. This meta-information is extremely valuable both for debugging and for later evaluations in operation.

Code Examples for Practical Applications

a) Simple Examples

Imagine you are running a library or an API to manage borrowing processes. Everywhere important actions take place—such as registering a book, registering new users, or handling requests—you want to create log entries. You could use a helper class for this:

public static class Logger
{
    public static void LogOperation(
        string operation, 
        [CallerMemberName] string memberName = "",
        [CallerFilePath] string filePath = "",
        [CallerLineNumber] int lineNumber = 0)
    {
        // For example, log to a file or a database
        Console.WriteLine($"Operation: {operation} in {memberName}, File: {filePath}, Line: {lineNumber}");
    }
}

Every time you call Logger.LogOperation("BookBorrowed"), the log provides much more information than if you had to add it manually.

b) More Complex Example with a Base Class

In larger projects, it is advisable to centralize logging and error handling routines in an abstract base class. The following example shows an abstract BaseRepository that catches errors and automatically uses the attributes for meaningful error messages:


public abstract class BaseRepository
{
    protected void LogError(Exception ex, 
                            [CallerMemberName] string memberName = "",
                            [CallerFilePath] string filePath = "", 
                            [CallerLineNumber] int lineNumber = 0)
    {
        Console.WriteLine($"Error in {memberName} at {filePath} (Line {lineNumber}): {ex.Message}");
    }
}

public class BookRepository : BaseRepository
{
    public void AddBook(Book book)
    {
        try
        {
            // Simulated database operation
            throw new InvalidOperationException("Database error while adding a book.");
        }
        catch (Exception ex)
        {
            LogError(ex);
            throw;  // Re-throw the error to continue the stack
        }
    }
}

public class LibraryService
{
    private readonly BookRepository _repository = new BookRepository();

    public void Execute()
    {
        try
        {
            _repository.AddBook(new Book { Title = "C# Deep Dive" });
        }
        catch (Exception ex)
        {
            Console.WriteLine("Error in the service layer: " + ex.Message);
            throw;
        }
    }
}

// Application
var service = new LibraryService();
service.Execute();

This approach allows complete tracking of the call stack. When an error is triggered in BookRepository, the LogError method precisely logs the context: the member name (AddBook), the file path, and the line number. At the same time, the error is re-thrown so that the higher layer (LibraryService) can perform further actions, such as separate logging or sending an alert.

c) Tracking a Complete Stack

In complex multi-layered architectures—consisting of service layers, repository layers, and database connections—it is crucial to trace the source of an error without gaps. The above example demonstrates this flow:
1. The service layer calls AddBook in BookRepository.
2. The repository layer throws an exception due to a database error, logs details using the caller attributes, and re-throws the error.
3. The service layer catches the error and can handle it accordingly.

With this technique, precise logging of each relevant layer is achieved, ensuring that no information about the actual origin is lost.

Practical Application with a Library Management System

In library software, where daily borrowings, reservations, returns, or new registrations are logged, the caller attributes are used optimally:
1. Logging API Errors: If an HTTP request fails, the log immediately provides information about the error location in the code (method, file, line).
2. Logging Database Operations: In dynamic environments, faulty SQL queries or transaction conflicts can quickly lead to confusing errors. Thanks to the caller attributes, it is possible to determine exactly where these conflicts were triggered, whether in the repository or service layer.

Such practical insights into the system not only shorten debugging times but also improve the overall maintainability of the application.

Limitations and Best Practices

Although logging file and line details is very helpful during development, it is important to consider potential drawbacks:
• Performance Considerations: With frequent log calls, excessive capturing of caller information can quickly bloat logs and impact application performance. Therefore, in production environments, it should be carefully considered where detailed logs are truly necessary.
• Security Aspects: Revealing file paths may be undesirable in some cases, such as in security-critical applications or externally shared logs.
• Reusability: To keep maintenance effort low, it is recommended to encapsulate the attributes in base classes or utility methods, as shown in the example (BaseRepository). This avoids redundant code and ensures consistent error messages across the entire project.

With a sensible logging concept and thoughtful filtering mechanisms, the level of detail can be flexibly controlled depending on the environment (development, staging, production).

Conclusion

The attributes [CallerMemberName], [CallerFilePath], and [CallerLineNumber] offer significant benefits for debugging, logging, and error tracing in C# projects. Their versatile applications—from simple logs in the development environment to complex error tracking in multi-layered architectures—make them essential tools in modern application development.

So why not start implementing more precise error logging and more efficient debugging in your own projects right away? The implementation is straightforward, while the benefits are enormous—especially when errors in production systems need to be quickly isolated and resolved. With targeted use, thoughtful structuring, and a bit of pragmatism, a new level of transparency in error analysis is achieved, significantly easing the developer’s daily work.

A Critical Look at Cancellation Management in .NET Applications

Ben Witt — Wed, 29 Jan 2025 17:01:36 +0000

The CancellationToken and the related types provided in .NET offer a central and effective foundation for carefully canceling tasks, threads, or asynchronous processes. However, the question arises whether this concept truly provides sufficient flexibility and stability in all application scenarios. But how often is this feature actually used in practice, and what risks come with improper handling? This article explains how the CancellationToken works and offers concrete recommendations for its efficient use. Additionally, potential pitfalls are highlighted and critically examined.

Definition and Purpose of CancellationToken

The CancellationToken is a structure from the Task Parallel Library (TPL) that is used to signal an ongoing operation that a cancellation request has been made. In a software architecture increasingly based on asynchronous and parallel processes, the CancellationToken plays a central role: it allows computationally intensive processes or long-running tasks to be terminated early, conserving resources and ensuring an improved user experience.

Why is this construct indispensable? In a modern .NET application, numerous operations can run in parallel or asynchronously. Without coordinated cancellation and resource release, there is a risk that certain tasks continue running and block system resources, even though they are no longer needed.

How It Works and Basic Concepts

Cancellation control is managed by the CancellationTokenSource class. It acts as the central control unit and provides methods such as Cancel(), which sends a cancellation signal to all linked CancellationTokens.

Resource Management with IDisposable

A frequently underestimated aspect is that CancellationTokenSource implements the IDisposable interface. If this is not taken into account, it can easily lead to resource leaks—especially in scenarios where a large number of CancellationTokenSource objects are created in parallel. Why should one neglect implementing clean resource management?

The recommendation is to always use the using keyword to enforce automatic resource release:

using (var cts = new CancellationTokenSource())
{
    // Code to execute the operation
}

Failing to call the Dispose() method can leave unmanaged resources in memory, ultimately affecting the application’s stability.

Methods to Cancel an Operation

There are several approaches to sending a cancellation request to an ongoing operation:
1. Synchronous Cancellation
The cancellation request is triggered immediately. This means the current method actively checks the CancellationToken and reacts right away.
2. Asynchronous Cancellation
The request is performed in the background without immediately blocking the calling code’s flow.
3. Delayed Cancellation
A predefined time span is used after which the operation is automatically terminated. This is especially helpful when a user does not want to wait further, such as in network or I/O-intensive tasks.

A concrete example of this is setting a timeout:

var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10));

After this time span elapses, a cancellation request is triggered, ensuring that an operation does not run beyond the set limits. But is it always sensible to set a rigid timeout without being able to flexibly respond to external events?

Monitoring Cancellation Requests

Polling

A common practice is to regularly check the CancellationToken:

while (!token.IsCancellationRequested)
{
    // Continue the operation
}

When such loops are implemented in computationally intensive areas, the frequency of checks can significantly affect performance. The question arises: How often should the check be performed to recognize a cancellation promptly without excessively burdening execution time?

Alternatively, the ThrowIfCancellationRequested() method can be used, which throws an OperationCanceledException if a cancellation request has been made:

token.ThrowIfCancellationRequested();

This approach is usually cleaner but can also lead to unexpected side effects if the exception is not caught appropriately.

Callback Registration

In scenarios where regular polling is impractical or resource-intensive, a callback can be registered to execute automatically when a cancellation request arrives. For example, if a user is downloading a large file and cancels the process, not only should the download threads stop, but any temporary files created should also be deleted to free up space and avoid inconsistencies.

token.Register(() => 
{
    Console.WriteLine("Operation canceled.");
    // Additional cleanup, e.g., deleting temporary files
});

This method has the advantage of calling cancellation actions specifically without the ongoing operation having to constantly check for the cancellation signal. However, callback registration can lead to messy code flow in complex scenarios when multiple cancellation cases and cleanup actions need to be considered.

Linking Multiple CancellationTokens

What happens when an application needs to meet several potential cancellation conditions at the same time? For example, an operation might need to respond to both a user event (like closing a window) and a timeout simultaneously. The CancellationTokenSource class provides the CreateLinkedTokenSource method for this purpose:

var linkedTokenSource = CancellationTokenSource.CreateLinkedTokenSource(token1, token2);

The created instance combines multiple CancellationTokens into a new token. Once any of the involved tokens is canceled, the combined token is also triggered. This simplifies the implementation of complex cancellation logic and improves readability. However, caution is necessary: incorrect linking can cause operations to be canceled too early or not at all if the relationships between tokens are not clearly defined.

Best Practices for Handling CancellationToken

To ensure smooth cancellation management, the following points should be considered:
1. Respect the Passed Token
Avoid ignoring the CancellationToken. In every relevant method, actively check it or use an appropriate mechanism (e.g., callback).
2. Properly Release Resources
Always call the Dispose() method on CancellationTokenSource, preferably using the using block to prevent memory leaks.
3. Avoid Unnecessary Sources
Only create a new CancellationTokenSource if passing an existing CancellationToken is insufficient. Otherwise, you risk an unclear codebase and unnecessary resource consumption.
4. Proper Error Handling
Catch the OperationCanceledException and handle it meaningfully. Silently swallowing the exception can lead to hard-to-trace error patterns, as cancellation operations behave “invisibly.”

Additional Aspects and Critical Consideration

Use Cases for Timeouts

While the use of a timeout has already been mentioned, in a highly connected world, variable external factors such as fluctuating network bandwidths or different devices can quickly render a rigid timeout obsolete. Wouldn’t it make sense to take a closer look at adaptive timeout management?

Consider scenarios where the system responds to environmental parameters and dynamically adjusts timeouts. For example, a microservice that reduces wait times for certain requests under high load or grants more generous timeouts with a good connection could significantly enhance user satisfaction. Load balancers and reverse proxies also play an important role here, as they can capture both the context and the load of the respective services.

In short, a purely time-based approach without context can lead to misjudgments and, at worst, prematurely cancel important operations. In the age of cloud computing and highly variable environments, it’s worthwhile to consider context-dependent timeout management with circuit breakers or retry mechanisms.

Depth of Example Implementations

Although the article uses concise code snippets (such as the using statement), a more in-depth presentation of more complex application examples would be helpful. Especially in microservice architectures or when accessing databases, the layered cancellation logic often becomes apparent in practice.

A realistic example could cover the following aspects:
• Multiple CancellationTokens originating from different sources (e.g., user inputs, timeouts, overload signals).
• A database-heavy operation accessing an external resource that, upon interruption, must not only reset local but also database transactions.
• Logical separation of cancellation handling at the service level and repository level to ensure a clear separation of concerns and minimize side effects.

Such comprehensive implementations would allow developers to recognize and avoid common pitfalls—such as forgetting to call Dispose() or improperly catching OperationCanceledException—in a realistic context.

More Comprehensive Error Handling

The article already emphasizes the importance of catching OperationCanceledException. But how specifically should the error situation be handled in complex systems where multiple components respond to the same token?

A possible scenario could look like this: A user-initiated cancellation request is recognized, but a downstream sub-component does not respond in time or blocks while requesting resources. Partial failures occur, which might only appear late in the logs and are difficult to attribute to a specific cause. In such cases, structured exception handling is needed, considering the following points:
• Targeted Logging: Every cancellation request should appear in the logs, ideally with context information (e.g., which sub-component responded, which actions were interrupted).
• Separation of Regular Exceptions and Cancellation Cases: An OperationCanceledException does not indicate a classic error state but a deliberate cancellation. However, the interplay of multiple CancellationTokens can create unforeseen side effects, making a consistent and well-documented error strategy essential.
• Fallback Mechanisms: In safety-critical or highly available environments, a cancellation should not lead to an unstable overall system but support orderly fallback procedures (e.g., graceful shutdown).

Especially in distributed architectures where multiple services and applications interact, a well-documented error handling and logging process is indispensable to make cancellation processes both traceable and controlled.

Conclusion

The CancellationToken is a central component in the development of modern, reactive, and resource-efficient .NET applications. However, its correct use requires a certain level of attention: underestimating the importance of clean resource management or ignoring cancellation signals in the code can lead to errors and performance problems almost by default.

Is it really acceptable to forgo this central cancellation mechanism or implement it only half-heartedly? Those who value scalability and user satisfaction will clearly answer no. Consistently following the described best practices leads to robust and controlled cancellation management, enhances application performance, and improves the user experience equally. At the same time, a critical look at advanced concepts such as adaptive timeout management, comprehensive implementation examples, and structured error handling is recommended to make the use of CancellationToken even more effective and secure.

Asynchronous HTTP Requests – Explained Simply

Ben Witt — Wed, 29 Jan 2025 17:01:17 +0000

Imagine a waiter taking your order and waiting in the kitchen until your food is ready. During this time, the waiter cannot serve other guests. This is how a synchronous HTTP request works – it blocks the process.

An asynchronous HTTP request, on the other hand, allows the waiter to serve other guests while your food is being prepared. Once your dish is ready, the waiter brings it to you without others being delayed. Sounds efficient, right?

Why Are Asynchronous Requests So Important?

In daily life, we encounter asynchronous HTTP requests all the time, for example:
• WhatsApp: Messages are loaded while you’re using other functions.
• Instagram: Images and videos are loaded in the background.
• Netflix: The next episode is preloaded while you’re still watching.
• Online Shopping: Products are filtered and sorted in the background.

What Does Idempotence Mean in This Context?

Idempotence is an essential concept in web development, particularly for HTTP requests. It describes the property of an operation that delivers the same result no matter how many times it is performed. This principle plays an important role in the reliability and repeatability of requests – especially with asynchronous HTTP requests, as they might be sent multiple times due to network failures or timeouts.

Examples of idempotent HTTP methods:
• GET: Repeatedly fetching the same resource always returns the same data (unless the resource changes).
• PUT: Overwriting a resource with the same data does not change the final state.
• DELETE: Deleting a resource has no effect if the resource has already been removed.

In contrast, POST is not idempotent because it often creates new resources or changes states, which can lead to inconsistent behavior when executed multiple times.

A Simple Introduction in C#

Here is an example of fetching weather data in C#, which also considers idempotence:

public class WetterService
{
    private readonly HttpClient _httpClient;

    public WetterService()
    {
        _httpClient = new HttpClient();
        _httpClient.BaseAddress = new Uri("https://api.wetter.de/");
    }

    public async Task<WetterDaten> HoleWetterAsync(string stadt)
    {
        try
        {
            var antwort = await _httpClient.GetAsync($"wetter/{stadt}");

            if (!antwort.IsSuccessStatusCode)
            {
                return new WetterDaten { Fehler = "Ups! Da ist etwas schiefgelaufen." };
            }

            var json = await antwort.Content.ReadAsStringAsync();
            return JsonSerializer.Deserialize<WetterDaten>(json);
        }
        catch (Exception)
        {
            return new WetterDaten { Fehler = "Sorry, wir konnten das Wetter nicht abrufen." };
        }
    }
}

Note: The use of the HTTP-GET method ensures idempotence. Even with multiple requests, the server’s state remains unchanged.

Practical Example: Online Shop

A typical controller processing asynchronous and idempotent requests:

[ApiController]
[Route("api/produkte")]
public class ProduktController : ControllerBase
{
    private readonly IProduktService _produktService;

    public ProduktController(IProduktService produktService)
    {
        _produktService = produktService;
    }

    [HttpGet]
    public async Task<ActionResult<List<Produkt>>> HoleAlleProdukte()
    {
        var produkte = await _produktService.HoleAlleProdukteAsync();
        return Ok(produkte);
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<Produkt>> HoleProdukt(int id)
    {
        var produkt = await _produktService.HoleProduktAsync(id);

        if (produkt == null)
        {
            return NotFound("Produkt nicht gefunden");
        }

        return Ok(produkt);
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> LoescheProdukt(int id)
    {
        var erfolgreich = await _produktService.LoescheProduktAsync(id);

        if (!erfolgreich)
        {
            return NotFound("Produkt nicht gefunden oder bereits gelöscht.");
        }

        return NoContent();
    }
}

Idempotence in detail: Both GET and DELETE are idempotent here. Even with multiple executions, the results remain consistent, enhancing the system’s stability.

Benefits of Asynchronous and Idempotent HTTP Requests
1. Better User Experience: The app remains responsive and does not freeze.
2. More Efficient Resource Utilization: The server can handle other tasks during wait times.
3. Increased Reliability: Repeated requests do not lead to inconsistent behavior thanks to idempotence.
4. Scalability: Asynchronous processing reduces bottlenecks, especially with parallel requests.

Advanced Use Case: Parallel Loading

Sometimes it is necessary to load multiple resources simultaneously:

public class DashboardService
{
    private readonly IBenutzerService _benutzerService;
    private readonly IBestellungService _bestellungService;

    public async Task<DashboardDaten> HoleDashboardDatenAsync()
    {
        var benutzerTask = _benutzerService.HoleStatistikenAsync();
        var bestellungenTask = _bestellungService.HoleStatistikenAsync();

        await Task.WhenAll(benutzerTask, bestellungenTask);

        return new DashboardDaten
        {
            BenutzerStats = await benutzerTask,
            BestellungStats = await bestellungenTask
        };
    }
}

Common Pitfalls and Solutions
1. Forgotten await: Without await, the code remains blocking and loses its asynchronous behavior.
2. Neglecting Error Handling: Network issues are common, so plan for appropriate error handling.
3. Not Setting Timeouts: Avoid endless wait times by implementing timeout rules.
4. Ignoring Idempotence: Non-idempotent requests can lead to hard-to-trace errors.
5. Lack of Tests: Asynchronous code is prone to subtle bugs and should be thoroughly tested.

Conclusion

Asynchronous HTTP requests are the foundation of modern, responsive applications. By adhering to idempotence principles, repeated requests do not produce unexpected results. Together, they not only enhance the user experience but also create robust and scalable systems. However, their proper implementation requires careful planning and execution.

WPF Application with Plugin Architecture

Ben Witt — Tue, 15 Oct 2024 08:00:00 +0000

In modern software architectures, plug-in systems offer a flexible and modular way of extending software without changing the core of the application. A specific WPF project will be used to show how a plug-in architecture can be implemented to create loosely coupled and extensible components. The focus is on the interaction between the main application, plug-ins and the use of a central event aggregator for communication between the components.

Overview over the structure

The plug-in interface

Central to any plug-in system is the definition of a clear interface that all plug-ins must implement. This creates consistency and ensures that the main application and the plug-ins can interact seamlessly with each other. In our example, this is achieved through the IPlugin interface:

namespace MyPluginInterface
{
  public interface IPlugin
  {
    string Name { get; }
    IEnumerable<Type> ViewTypes { get; } 
    IEnumerable<Type> ViewModelTypes { get; }
  }
}

This interface specifies that each plug-in provides a name, a list of views (ViewTypes) and the associated ViewModels (ViewModelTypes). This ensures that all plug-ins can be uniformly integrated into the application.

Implementation of a plug-in

A typical plug-in in this system implements the IPlugin interface. In the following example, the plug-in provides two views and the corresponding ViewModels:

using MyFirstPlugin.ViewModels;
using MyFirstPlugin.Views;
using MyPluginInterface;

namespace MyFirstPlugin
{
  public class MyFirstPlugin : IPlugin
  {
    public string Name => "My First Plugin with Multiple Views";

    public IEnumerable<Type> ViewTypes => new List<Type>
    {
        typeof(MyPluginView),
        typeof(MyPlugin1View)
    };

    public IEnumerable<Type> ViewModelTypes => new List<Type>
    {
        typeof(MyPluginViewModel),
        typeof(MyPlugin1ViewModel)
    };
  }
}

This plug-in defines two views (MyPluginView, MyPlugin1View) and their associated ViewModels (MyPluginViewModel, MyPlugin1ViewModel). This makes it possible to define various UI components within the plug-in that can be integrated into the main application.

Dynamic loading and registration of plug-ins

One of the central functions of a plug-in system is the dynamic loading of plug-ins at runtime. This is done by searching for and loading assemblies that implement the plug-in interface. The following code in the main application shows how this is achieved:

private void LoadPlugins(ContainerBuilder builder)
{
  var pluginPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Plugins");
  var pluginFiles = Directory.GetFiles(pluginPath, "*.dll");

  foreach (var pluginFile in pluginFiles)
  {
    var assembly = Assembly.LoadFrom(pluginFile);
    var pluginTypes = assembly.GetTypes().Where(t => typeof(IPlugin).IsAssignableFrom(t) && !t.IsInterface && !t.IsAbstract);

    foreach (var pluginType in pluginTypes)
    {
      var plugin = (IPlugin)Activator.CreateInstance(pluginType);

      foreach (var viewType in plugin.ViewTypes)
      {
        builder.RegisterType(viewType).AsSelf().InstancePerDependency();
      }

      foreach (var viewModelType in plugin.ViewModelTypes)
      {
        builder.RegisterType(viewModelType).AsSelf().InstancePerDependency();
      }

      builder.RegisterInstance(plugin).As<IPlugin>();

      // Registers the views and ViewModels
      builder.RegisterViewsAndViewModels(assembly);
    }
  }
}

Here, a directory is searched for plug-ins that are stored as DLLs. Each plug-in is loaded dynamically and the views and ViewModels defined in it are registered with Autofac in the dependency injection container.

Automatic registration of views and ViewModels with Autofac

We use an extended function of Autofac for efficient registration of views and ViewModels:

public static class AutofacExtensions
{
  public static void RegisterViewsAndViewModels(this ContainerBuilder builder, Assembly assembly)
  {
    builder.RegisterAssemblyTypes(assembly)
           .Where(t => t.Name.EndsWith("View") && typeof(FrameworkElement).IsAssignableFrom(t))
           .OnActivated(args =>
           {
             var viewType = args.Instance.GetType(); 
             var viewModelTypeName = viewType.Name.Replace("View", "ViewModel");
             var viewModelType = viewType.Assembly.GetType(viewType.Namespace + "." + viewModelTypeName); 

             if (viewModelType == null)
             {
               viewModelType = assembly.GetTypes().FirstOrDefault(t => t.Name == viewModelTypeName);
             }

             if (viewModelType != null)
             {
               var viewModel = args.Context.Resolve(viewModelType);
               ((FrameworkElement)args.Instance).DataContext = viewModel;
             }
           })
           .AsSelf()
           .InstancePerDependency();

    builder.RegisterAssemblyTypes(assembly)
           .Where(t => t.Name.EndsWith("ViewModel"))
           .AsSelf()
           .InstancePerDependency();
  }
}

This method registers all Views and ViewModels of a plug-in based on naming conventions. Views that end with 'View' are registered and the associated ViewModels are also identified and loaded into the DI container.

Communication between plug-ins via the EventAggregator

In complex applications, the plug-ins must communicate with each other without creating direct dependencies in order to ensure modularity. In our project, this is made possible by the EventAggregator. Here is a concrete example from the MyFirstPlugin:
Plugin 1: Send message:

public class MyPlugin1ViewModel
{
    private readonly IEventAggregator _eventAggregator;

    public ICommand MyCommand { get; }

    public MyPlugin1ViewModel(IEventAggregator eventAggregator)
    {
      _eventAggregator = eventAggregator;
      MyCommand = new RelayCommand(_ => OnButtonClick());
    }

    private void OnButtonClick()
    {
      var msg = new SpecialEvent("Hello from the other view internal my first plugin");
      _eventAggregator.Publish(msg);
    }
}

In this example, the MyPlugin1ViewModel sends a special event, SpecialEvent, with a message when the user presses a button.

Plugin 2: Receive message
The second plug-in can subscribe to this event and process the message:

public class MySecondPluginViewModel : IHandle<SpecialEvent>
{
    private readonly IEventAggregator _eventAggregator;

    public MySecondPluginViewModel(IEventAggregator eventAggregator)
    {
        _eventAggregator = eventAggregator;
        _eventAggregator.Subscribe(this);
    }

    public void Handle(SpecialEvent message)
    {
        // Process message
        Console.WriteLine(message.Content);
    }
}

In this example, MySecondPluginViewModel receives the SpecialEvent and processes its content in the handle method. This ensures that the two plug-ins can communicate via the EventAggregator without being directly dependent on each other.

Conclusion

A plug-in architecture offers a flexible and scalable solution for extending an application. In our example, this architecture is realised through the combination of Autofac for dependency injection and an event aggregator for communication between the components. Such systems are ideal for scenarios in which an application needs to be dynamically extended with new functionalities without changing the core of the application.

plugIn architecture

HealthChecks

Ben Witt — Tue, 08 Oct 2024 08:00:00 +0000

From time to time it happens that the connection to the database fails or the services or containers crash. This can lead to a considerable investigation effort to find the reasons why these problems occur, which can be facilitated by the use of “HealthChecks”.

ASP.NET provides a convenient and effective approach to implementing this functionality.

To achieve this, the following nuggets need to be installed:

To include the following items in the Program.cs file:

builder.Services.AddHealthChecks();  
...  
...  
//Now the HealthChecks should be mapped to the current endpoint  
app.MapHealthChecks("/_health");

This would provide us with the foundation to check the health of our application. Currently, no checks are performed, so our application is considered to be in a healthy state.

Upon launching the app, initially, only the Swagger site is loaded and no other content is visible. Let’s simply update the address to:

To extend our HealthCheck with a custom check, we will create a new class called “MyFirstHealthCheck” with the following content:

public class MyFirstHealthCheck : IHealthCheck  
{    
  public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)    
  {      
    return Task.FromResult(HealthCheckResult.Healthy("This could be a service"));    
  }  
}

This class serves the purpose of returning a “HealthCheckResult” with the status “Healthy”.

We have reached a point where we need to include this check in our Program.cs file. When we call this check, the situation looks a little different. Initially, the appearance remains unchanged. However, if we set a breakpoint in the source code, it will be triggered when we refresh the page.

Instead of using the term “healthy”, which is not very meaningful, it would be more helpful to convey a specific message. For example, we could use a more descriptive message to communicate the status or result of the test.

To accomplish this, we need to ensure that the NuGet package “AspNetCore.HealthChecks.UI.Client” is installed. After that, we can proceed to extend the following functionality:

In the Program.cs file, we need to incorporate a ResponseWriter into the mapper of the HealthCheck. This will enable us to customize the output or response generated by the HealthCheck module.

Let’s restart the program and see what comes out of it.

To enable easy retrieval from a list, we can assign a tag to this check. Implementing the tag in the service would facilitate the process.

Now let’s execute this request once more.

Let’s create another check:

It can be a bit overwhelming at first.

To create a dashboard that lists all our checks using the NuGet package “AspNetCore.HealthChecks.UI.Client," we need to make three additions to the Program.cs file:

1. Add a new service:

This new dashboard requires persistent storage, so we need to add the NuGet package “AspNetCore.HealthChecks.UI.InMemory.Storage."

2. New Mapping

Below the previous AddHealthChecks() method call, we can add a new method call AddHealthChecksUI() that uses the in-memory store.

To map this new user interface, we can add a route to the Configure() method in the Startup.cs file. The route should point to the Health Checks UI endpoint.

3.) AppSettings.json

To configure the dashboard to forward requests to the appropriate address, you can modify the appsettings.json file. Within the file, you will need to update the relevant settings to specify the desired address for request forwarding.

We start the application and change the address:

Now our dashboard opens:

By utilizing the dashboard we have created, we can now have a comprehensive overview of the checks we have implemented for our application. The dashboard not only displays the current status of the checks but also provides a history section that gives us insights into the events that have occurred from the application’s start until now. To access more detailed information, we can explore the details section within the dashboard.

What could a HealthCheck that monitors the connection to the database look like?

We create a new object that checks the connection to the database.

public class DatabaseConnectionCheck : IHealthCheck
{
  public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
  {
    try
    {
      using var connection = new SqlConnection("Data Source=.;Initial Catalog=MyDatabase;Integrated Security=True;Connect Timeout=30;Encrypt=False;Trust Server Certificate=False;Application Intent=ReadWrite;Multi Subnet Failover=False");
      await connection.OpenAsync(cancellationToken).ConfigureAwait(false);
      using var command = connection.CreateCommand();
      command.CommandText = "Select 1";
      object result = await command.ExecuteScalarAsync(cancellationToken).ConfigureAwait(false);

      return HealthCheckResult.Healthy("The status of the connection is open");
    }
    catch (Exception ex)
    {
      return HealthCheckResult.Unhealthy("The status of the connection is close");
    }

  }
}

Here only the connection to the database is established and by the select 1 it is checked whether the query can be sent or not. Accordingly, a result is returned which is healthy or unhealthy.

Now we only have to announce the service:

Now we have a comprehensive overview of all the checks that have been configured in our application. This provides a clear and organized display of the various checks and their respective statuses, making it easier to monitor and track the health of our application.

these checks are queried every 5 seconds as we set, now if the connection to the database is closed or interrupted, this dashboard will react to it:

you will find a number of nuget dealing with some topics:

Github: HealthChecks

DBConcurrency with EF Core

Ben Witt — Tue, 01 Oct 2024 08:00:00 +0000

What is concurrency in the database?

Concurrency is the simultaneous processing of data by multiple users or processes. In a database environment, this can lead to conflicts if two transactions attempt to access the same data at the same time.

Why is concurrency control important?

Concurrency control is important to ensure that multiple processes or threads can run simultaneously in a system without causing unexpected problems. This is important for efficient resource utilisation, data consistency and avoiding race conditions and deadlocks. Effective concurrency control improves the overall performance of systems, especially in multi-core environments, and contributes to a stable and user-friendly experience.

Conflict detection in Entity Framework Core

Entity Framework Core offers mechanisms for recognising conflicts.

In Entity Framework Core, conflict detection is often activated by the “Timestamp” attribute or the “ConcurrencyCheck” attribute.

„Timestamp” attribute:

Purpose: The “Timestamp” attribute is used to detect conflicts with concurrent updates in Entity Framework Core.
How it works: When the Timestamp attribute is applied to a property, Entity Framework Core automatically creates a database column of type RowVersion. This column is automatically updated with every update. If two updates occur simultaneously, the system recognises a conflict based on this column.

public class Employee
{
  public int Id { get; set; }
  public string FirstName { get; set; } = string.Empty;
  public string LastName { get; set; } = string.Empty;

  public string Fullname => $"{FirstName} {LastName}";

  public string Department { get; set; } = string.Empty;
  public int EntryYear { get; set; }

  [Timestamp]
  public byte[] Version { get; set; }
}

„ConcurrencyCheck“ attribute:

Purpose: The “ConcurrencyCheck” attribute is also used to detect conflicts during updates by ensuring that no changes were made to certain properties during the update.
How it works: When the ConcurrencyCheck attribute is applied to a property, Entity Framework Core compares the value of that property during the update with the value stored in the database. If differences are detected, a conflict is recognised.

public class Employee
{
  public int Id { get; set; }
  public string FirstName { get; set; } = string.Empty;
  public string LastName { get; set; } = string.Empty;

  public string Fullname => $"{FirstName} {LastName}";

  public string Department { get; set; } = string.Empty;
  public int EntryYear { get; set; }

  [ConcurrencyCheck]
  public byte[] RowVersion { get; set; }
}

Both approaches serve to ensure that database updates can be carried out consistently and without conflict, even if several users access the database at the same time.

Strategies for conflict resolution

When resolving conflicts in an application, there are various strategies to ensure that simultaneous updates of data are consistent and without data inconsistencies. Here are some common strategies:

Last writer wins (lww):

Description: the last update written to the database is considered the valid version.
Implementation: If a conflict occurs, the update with the most recent timestamp or transaction ID is favoured.

Extended conflict resolution (Custom Conflict Resolution):

Description: custom logic is implemented to resolve conflicts based on application logic or user preferences.
Implementation: Developers determine how conflicts should be handled, possibly through user interaction or specific business rules.

Optimistic conflict resolution:

Description: It is assumed that conflicts rarely occur, so that the data is updated without prior blocking. Conflicts are only checked when data is written to the database.
Implementation: Use of mechanisms such as Timestamp or ConcurrencyCheck attributes. In the event of a conflict, an exception is raised and the application can react.

Pessimistic conflict resolution:

Description: data is locked throughout the update process to ensure that no other updates can be performed at the same time.
Implementation: Use of explicit locks or transaction isolation levels to ensure that no other operations can access the locked data at the same time.

Automatic merging:

Description: In the event of conflicts, changes are automatically merged if this is possible. This is often used in distributed version control systems or collaborative tools.
Implementation: Automatic merging algorithms are used to recognise and automatically resolve conflicts.

The choice of the appropriate strategy depends on the requirements of the application, the type of data and the expected usage patterns. It is important to choose a strategy that ensures data consistency and at the same time does not impair the performance and user-friendliness of the application.

Implementation of concurrency control in a sample application

Example:

Assume you have an “Employee” entity class with a “LastName” property and a timestamp attribute for concurrency control:

public class Employee
{
public int Id { get; set; }
public string FirstName { get; set; } = string.Empty;
public string LastName { get; set; } = string.Empty;

public string Fullname => $"{FirstName} {LastName}";

public string Department { get; set; } = string.Empty;
public int EntryYear { get; set; }
[Timestamp]
public byte[] Timestamp { get; set; } // Timestamp-Eigenschaft für Concurrency
}

And here’s how you can use the ConcurrencyCheck attribute for concurrency control in an entity class:

public class Employee
{
  public int Id { get; set; }
  public string FirstName { get; set; } = string.Empty;
  public string LastName { get; set; } = string.Empty;

  public string Fullname => $"{FirstName} {LastName}";

  public string Department { get; set; } = string.Empty;
  public int EntryYear { get; set; }

  [ConcurrencyCheck]
  public byte[] RowVersion { get; set; }
}

In your DbContext, you can then specify that the timestamp row acts as RowVersion:

In our example, we select the “ConcurrencyCheck”

public void Configure(EntityTypeBuilder<Employee> builder)
 {
   builder.HasKey(c => c.Id);
   builder.Property(c => c.Id).ValueGeneratedOnAdd();
   builder.Property(rv => rv.RowVersion).IsRowVersion();
 }

Conflict simulation:

To simulate a concurrency conflict, you can perform the following steps:

Assume you already have an employee in your database:

var loadedEmployee = dbContext1.Employees.Find(id);

Now we simulate a conflict by updating the lastname both in the database and in the application:

// Changes in the database by another process

var existingEmployeeInDatabase = dbContext2.Employees.Find(id);


if (loadedEmployee != null && existingEmployeeInDatabase != null)
 {
   // Change only loadedEmployee
   loadedEmployee.LastName = "NewLastName1";

   try
   {
     dbContext1.SaveChanges();  // Save changes in LoadedEmployee
   }
   catch (DbUpdateConcurrencyException ex)
   {
     Console.WriteLine($"Concurrency conflict on LoadedEmployee: {ex.Message}");
     // Here you can implement conflict handling, e.g. retry or report errors to the user interface.
   }

   // Change existingEmployeeInDatabase now
   existingEmployeeInDatabase.LastName = "NewLastName2";

   try
   {
     dbContext2.SaveChanges();  // Try to save changes in existingEmployeeInDatabase, which should throw a DbUpdateConcurrencyException
     Console.WriteLine("Records updated successfully.");
   }
   catch (DbUpdateConcurrencyException ex)
   {
     Console.WriteLine($"Concurrency conflict on existingEmployeeInDatabase: {ex.Message}");
     // Here you can implement conflict handling, e.g. retry or report errors to the user interface.
   }
 }

In this example, dbContext2.SaveChanges() will throw a DbUpdateConcurrencyException because the database version of the product no longer matches the one in your application.

You can now implement the conflict resolution logic to decide how to deal with this conflict. This can include applying strategies such as “client wins”, “database wins” or customised conflict resolution.

Here is an example of the client wins strategy:

using (var dbContext1 = Create.Context())
 using (var dbContext2 = Create.Context())
 {
   var loadedEmployee = dbContext1.Employees.Find(id);
   var existingEmployeeInDatabase = dbContext2.Employees.Find(id);

   if (loadedEmployee != null && existingEmployeeInDatabase != null)
   {
     // Change only loadedEmployee
     loadedEmployee.LastName = "NewLastName1";

     try
     {
       dbContext1.SaveChanges();  // Save changes in LoadedEmployee
     }
     catch (DbUpdateConcurrencyException ex)
     {
       Console.WriteLine($"Concurrency conflict on LoadedEmployee: {ex.Message}");

       ex.Entries.Single().Reload();
       dbContext1.SaveChanges(); 
       Console.WriteLine("Client Wins: Records updated successfully.");
     }

     // Change existingEmployeeInDatabase now
     existingEmployeeInDatabase.LastName = "NewLastName2";

     try
     {
       dbContext2.SaveChanges();  // Try to save changes in existingEmployeeInDatabase, which should throw a DbUpdateConcurrencyException
       Console.WriteLine("Records updated successfully.");
     }
     catch (DbUpdateConcurrencyException ex)
     {
       Console.WriteLine($"Concurrency conflict on existingEmployeeInDatabase: {ex.Message}");
       // Here you can implement conflict handling, e.g. retry or report errors to the user interface.
     }
   }
 }

Concurrency proves to be essential by enabling simultaneous access to database resources. Precise handling of DBConcurrency minimises potential conflicts, ensures data consistency and guarantees integrity in dynamic environments. Clever implementation of mechanisms such as transaction control and locking procedures not only optimises synchronisation, but also increases performance. In complex applications that access shared databases, the accurate handling of concurrency is crucial for a robust system architecture and smooth functioning under intensive load.
GitHub: DBConcurrency

Basics of Clean Architecture with C#

Ben Witt — Tue, 24 Sep 2024 08:00:00 +0000

This article covers the basics of Clean Architecture with C#. Readers will be empowered to develop solid, well-structured code that excels in maintainability, extensibility, and testability.

Introduction to Clean Architecture

What is Clean Architecture?
Clean Architecture, proposed by Robert C. Martin or “Uncle Bob,” is an architectural pattern for software projects aimed at keeping the code clean, modular, and independent of external influences. It isolates the business logic of the application from external details such as user interfaces, databases, and frameworks.

Why is Clean Architecture important?
Clean Architecture offers a variety of advantages:

High Maintainability: The clear separation of business logic and technical details facilitates understanding of the code and enhances its maintainability.

2.** Extensibility**: Thanks to the well-structured architecture, new features can be added or existing ones modified easily without jeopardizing the integrity of the overall application.

Testability: The clean separation of components simplifies the writing of automated tests, thereby improving the quality of the software.
Independence from external influences: By using abstractions and interfaces, the application remains flexible and is not tied to specific technologies or frameworks.

The benefits of Clean Architecture include:

Clear Separation of Responsibilities: The clear structure defines the responsibilities of the various components, leading to better-organized code.
Minimization of Dependencies: Clean Architecture minimizes dependencies between different parts of the application, enhancing flexibility and maintainability.
Facilitation of Testing: The clean separation of components allows tests to focus on individual parts of the application, improving testability and software quality.
Support for Scalability and Extensibility: The modular structure of Clean Architecture makes it easier to scale the application and add new features without redesigning the entire architecture.

The Principles of Clean Architecture

Separation of Concerns:
This principle demands that various aspects of a software application, such as user interface, business logic, and data persistence, be separated from each other. This leads to better-structured and more maintainable code.

Dependency Rule:
The dependency rule states that dependencies within an application should always point towards stable layers. For example, the business logic layer should not have direct dependencies on the user interface or databases.

Stable Dependencies Principle:
This principle dictates that dependent components should be more stable than the components they depend on. This means that high-level modules should not depend on low-level modules.

Stable Abstractions Principle:
Here, the abstraction should be more stable than the concrete implementation. Abstractions should be independent of concrete implementations.

These principles form the backbone of Clean Architecture and contribute to creating a robust and flexible software architecture. Now, let’s take a look at the components of Clean Architecture.

The Components of Clean Architecture

Clean Architecture comprises various components designed to divide the application into clearly defined layers. Here are the main components:

1. Dependency Inversion Principle: This principle states that dependencies should depend on abstract interfaces, not concrete implementations. This decouples the layers and increases the flexibility and testability of the application.

2. Entities: Entities represent the core objects of the application, representing the state and behavior of the business logic. They are independent of the database or other external systems.

3. Use Cases: Use Cases contain the application logic and define how user interactions are handled. They are independent of the user interface and other external systems.

4. Interface Adapters: These adapters connect the application to external systems such as databases, APIs, or user interfaces. They convert data and calls into formats that can be processed by the core application.

5. Frameworks & Drivers: This layer contains external frameworks and drivers used by the application, such as web frameworks, database drivers, or user interface libraries.

By clearly separating these components, changes can be made in one area of the application without affecting other areas. This makes the application flexible and easier to maintain.

Implementation of Clean Architecture in C# (Continued)

Implementing the Project Structure:

1. Creating the Core Layer:

Define Entities and Use Cases.
Create a folder named “Core.”
Within this folder, classes for Entities such as “User.cs” or “Product.cs” are created.
Create interfaces or abstract classes for Use Cases like “IUserService.cs” or “IProductService.cs”.

2. Creating the Application Layer:
Implement Use Cases.
Create a folder named “Application.”
Implement Use Cases as classes that inherit from the interfaces defined in the Core layer.
For example: “UserRegistrationService.cs”, “ProductManagementService.cs”.

3. Creating the Infrastructure Layer:
Implement Interface Adapters.
Create a folder named “Infrastructure.”
Implement concrete classes for the interfaces defined in the Core layer.
For example: “UserRepository.cs” for “IUserRepository”.

4. Creating the Presentation Layer:
Implement user interface or API controllers.
Create a folder named “Presentation.”
Implement controllers, such as ASP.NET MVC controllers or WebAPI controllers.

Implementing Entities:

Entities represent the core objects of the application and include the state and behavior of the business logic. Here’s an example of a “User” Entity:

namespace CleanArchitectureExample.Core.Entities;

public class User
{
  public int Id { get; set; }
  public string Username { get; set; }
  public string Email { get; set; }
}

With this structure, we lay the foundation for a clean and modular architecture that is easily maintainable and extensible.

Implementing Use Cases:

Use Cases contain the application logic and define how user interactions are processed. Here’s an example of a “UserRegistration” Use Case:

namespace CleanArchitectureExample.Core.UseCases;

public interface IUserRegistrationUseCase
{
  void RegisterUser(string username, string email);
}

namespace CleanArchitectureExample.Application.Services;

public class UserService : IUserRegistrationUseCase
{
  private readonly IUserRepository _userRepository;

  public UserService(IUserRepository userRepository)
  {
    _userRepository = userRepository;
  }

  public IUserRepository GetUserRepository()
  {
    return _userRepository;
  }

  public void RegisterUser(string username, string email)
  {
    // The user registration logic is implemented here
    var newUser = new User { Username = username, Email = email };

    _userRepository.AddUser(newUser);
    Console.WriteLine($"User {username} with the email {email} was successfully registered.");
  }
}

Implementing Interface Adapters:

Interface Adapters connect the application to external systems such as databases or APIs. Here’s an example of a UserRepository implementing the database access interface:

namespace CleanArchitectureExample.Infrastructure;

public interface IUserRepository
{
  void AddUser(User user);
}

public class UserRepository : IUserRepository
{
  public void AddUser(User user)
  {
    // This is where the logic for adding a user to the database would be implemented
    Console.WriteLine($"User {user.Username} has been added to the database.");
  }
}

Now, we will proceed to manage dependencies between components using Dependency Injection.

Implementation of Clean Architecture in C

Setting up Dependency Injection:
In this step, we will set up Dependency Injection (DI) in our C# project to manage dependencies between different components.

First, we need to configure a DI container in our project. We can use the built-in DI container library provided by .NET for this purpose. Here’s an example of how we can do this:

namespace CleanArchitectureExample;

class Program
{
  static void Main(string[] args)
  {
    // Configuration of the DI container
    var services = new ServiceCollection();
    services.AddTransient<IUserRepository, UserRepository>();
    services.AddTransient<IUserRegistrationUseCase, UserService>();

    // Create the DI container
    var serviceProvider = services.BuildServiceProvider();

    // Use the dependent components
    var userService = serviceProvider.GetService<IUserRegistrationUseCase>();
    userService.RegisterUser("Max Mustermann", "max@example.com");

    Console.ReadLine(); // Wait for user input so that the console application is not closed immediately
  }
}

In this example, we use the ServiceCollection class to register dependencies. With AddTransient, we specify that a new instance of the dependent class should be created each time it’s requested.

Once we have configured our DI container, we can use the dependent components in our classes. The DI container takes care of resolving and providing the dependent instances.

For example, the UserRegistrationService can access the IUserRepository like this:

namespace CleanArchitectureExample.Application.Services;

public class UserService : IUserRegistrationUseCase
{
  private readonly IUserRepository _userRepository;

  public UserService(IUserRepository userRepository)
  {
    _userRepository = userRepository;
  }

  public IUserRepository GetUserRepository()
  {
    return _userRepository;
  }

  public void RegisterUser(string username, string email)
  {
    // The user registration logic is implemented here
    var newUser = new User { Username = username, Email = email };

    _userRepository.AddUser(newUser);
    Console.WriteLine($"User {username} with the email {email} was successfully registered.");
  }
}

By using Dependency Injection, the components are loosely coupled, which improves the maintainability, extensibility, and testability of our application.

Testing in Clean Architecture

Testing is an integral part of Clean Architecture, ensuring that our application functions correctly and that changes do not introduce unwanted side effects. In Clean Architecture, we use various types of tests:

1. Unit Tests: These test individual components of our application in isolation. Mock objects can be used to simulate external dependencies.

2. Integration Tests: These test the collaboration of multiple components of our application to ensure they interact properly.

3. End-to-End Tests: These test the entire application from an external perspective, such as by executing user interactions through the user interface.

Test-Driven Development (TDD) Approach:

In the test-driven development approach, we first write tests that define the expected behavior of the application, and then implement the code that passes these tests. This approach promotes thorough test coverage and often leads to better code quality and structure.

Example Tests for Various Components:

Here is an example of a unit test for the UserRegistrationService:

[Fact]
  public void RegisterUser_Should_Register_User()
  {
    // Arrange
    var mockUserRepository = new Mock<IUserRepository>();
    var userService = new UserService(mockUserRepository.Object);
    var username = "John Smith";
    var email = "john@example.com";

    // Act
    userService.RegisterUser(username, email);

    // Assert
    mockUserRepository.Verify(repo => repo.AddUser(It.IsAny<User>()), Times.Once);
  }

In this test, we use a mock object for IUserRepository to simulate database access. We verify that the AddUser method of the repository was called once after registering a user.

Conclusion:

In this article, we’ve provided a comprehensive overview of the fundamentals of Clean Architecture with C#, covering everything from basic principles to practical implementation and testing. Clean Architecture offers a multitude of benefits for software project development, including improved maintainability, extensibility, and testability. By clearly separating responsibilities and minimizing dependencies, the code becomes more structured and easier to maintain. The use of Dependency Injection allows for flexible configuration of the application and facilitates testing by isolating components. Overall, Clean Architecture provides a robust approach to developing high-quality software that has proven itself in a variety of application domains.

Clean architecture

HybridCache in a console application with Redis

Ben Witt — Tue, 17 Sep 2024 08:00:00 +0000

In modern applications, the efficient management of data and the avoidance of unnecessary database queries is essential. An effective way to achieve this is to use a HybridCache, which utilises both a MemoryCache and a Distributed Cache such as Redis. In this article, I will present an implementation of a HybridCache in a console-only application and explain when to query which cache to achieve optimal performance. In addition, I will discuss the importance of cache invalidation and explain how this can be solved in the implementation.

What is a HybridCache?

A HybridCache combines several cache types in order to increase performance. In our case, we first access the fast, memory-based MemoryCache, and if no data is available there, we fall back on a distributed cache — in this case Redis. Only if neither cache returns a hit is a query sent to the database. This approach helps to minimise database queries and significantly reduce latency times.

Implementation of the HybridCache

I have created a console application that implements the HybridCache with Microsoft.Extensions.Caching.Memory and Redis. The following code shows the basic implementation where cache invalidation plays a role:

public class HybridCache : IHybridCache
{
    private readonly IMemoryCache _memoryCache;
    private readonly IDistributedCache _distributedCache;
    private static readonly object _lock = new object();  // Lock for thread-safety

    public HybridCache(IMemoryCache memoryCache, IDistributedCache distributedCache)
    {
        _memoryCache = memoryCache;
        _distributedCache = distributedCache;
    }

    public async Task<T> GetOrSetAsync<T>(string key, Func<Task<T>> factory, TimeSpan duration)
    {
        T value;

        // Check MemoryCache first
        lock (_lock)
        {
            if (_memoryCache.TryGetValue(key, out value))
            {
                string valueString = value.ToString();
                valueString = ReplaceSourceInfo(valueString, "MemoryCache");
                value = (T)Convert.ChangeType(valueString, typeof(T));
                return value;
            }
        }

        // Check Distributed Cache (Redis)
        var cachedData = await _distributedCache.GetStringAsync(key);
        if (cachedData != null)
        {
            value = System.Text.Json.JsonSerializer.Deserialize<T>(cachedData);

            string valueString = value.ToString();
            valueString = ReplaceSourceInfo(valueString, "Distributed Cache");
            value = (T)Convert.ChangeType(valueString, typeof(T));

            // Set the value in MemoryCache
            lock (_lock)
            {
                _memoryCache.Set(key, value, absoluteExpirationRelativeToNow: duration);
            }

            return value;
        }

        // Query the database if not found in any cache
        value = await factory();

        // Save the data to both MemoryCache and Redis
        string newValue = ReplaceSourceInfo(value.ToString(), "Database");
        value = (T)Convert.ChangeType(newValue, typeof(T));

        var serializedValue = System.Text.Json.JsonSerializer.Serialize(value);
        await _distributedCache.SetStringAsync(key, serializedValue, new DistributedCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = duration  // Set expiration time for Redis
        });

        lock (_lock)
        {
            _memoryCache.Set(key, value, duration);  // Set expiration time for MemoryCache
        }

        return value;
    }

    public void InvalidateCache(string key)
    {
        // Remove key from MemoryCache
        lock (_lock)
        {
            _memoryCache.Remove(key);
        }

        // Remove key from Distributed Cache (Redis)
        _distributedCache.Remove(key);
    }

    private string ReplaceSourceInfo(string originalValue, string source)
    {
        string patternToRemove = @"\(Source:.*?\)";
        string updatedValue = System.Text.RegularExpressions.Regex.Replace(originalValue, patternToRemove, "");
        return $"{updatedValue} (Source: {source})";
    }

    public async Task<T> GetAsync<T>(string key)
    {
        // Try getting the value from MemoryCache first
        lock (_lock)
        {
            if (_memoryCache.TryGetValue(key, out T value))
            {
                return value;
            }
        }

        // If not found, get the value from Distributed Cache
        var cachedData = await _distributedCache.GetStringAsync(key);
        return cachedData != null ? System.Text.Json.JsonSerializer.Deserialize<T>(cachedData) : default;
    }
}

Cache invalidation

In the above implementation, a simple time-based expiration is used to ensure that the cache entries in both the MemoryCache and the Redis Cache become invalid after a certain time. This is controlled by the AbsoluteExpirationRelativeToNow method, which determines when an entry expires automatically.
In addition, I have added an InvalidateCache method that enables manual invalidation of the cache entries. With this method, the cache entry can be explicitly deleted from both the MemoryCache and Redis if, for example, the underlying data in the database has been changed.

When is which cache used?

In this implementation, the HybridCache ensures that queries are made according to a clear hierarchy. MemoryCache is queried first, as it is faster. If no data is found there, the cache checks Redis. Redis is favoured in distributed systems as it can serve multiple instances of the application and therefore provides a central source for the cache data. Finally, if both caches fail, the database is queried.

Extended strategies for cache invalidation

manual/explicit invalidation: As shown in the code, there is an InvalidateCache method that can be used to manually remove cache entries. This is useful when data in the database changes and the cache contains outdated entries.
event-based invalidation: In distributed systems, an event-based model could be used to invalidate cache entries. If the data changes, a message could be sent (e.g. via a message queue system) that invalidates the cache entry in several instances simultaneously.
sliding expiration: Another possible strategy is sliding expiration, in which the expiration time of a cache entry is extended with each access. This ensures that frequently used data remains in the cache for longer, while unused data expires after a certain time. An example of sliding expiration could look like this:

var cacheEntryOptions = new DistributedCacheEntryOptions
{
    SlidingExpiration = TimeSpan.FromMinutes(5)  // Expiration is reset after each access
};

await _distributedCache.SetStringAsync(key, serializedValue, cacheEntryOptions);

Install Redis - locally or via Docker

Redis is used as a distributed cache for this application. Redis can be installed in various ways. An easy way to install Redis locally is to download the Redis binaries from the official website (https://redis.io/download). Once Redis is installed, it can be executed on the local host on the standard port 6379.
Alternatively, Redis can also be run via Docker.

Other options - e.g. with MS SQL Server

In addition to Redis, there are also other options for implementing a distributed cache. One widespread option is the use of an SQL-based cache, e.g. with Microsoft SQL Server. This solution is often used in environments where there is already a strong integration with SQL Server-based systems.

Conclusion

The implementation of a HybridCache in a console application offers numerous advantages, especially when it comes to reducing latency times and database queries. By combining a fast memory-based cache such as MemoryCache and a distributed cache such as Redis, application performance can be significantly increased. The introduction of thread safety and proper synchronisation ensures that parallel requests do not cause inconsistencies. Furthermore, cache invalidation is an important aspect to ensure that only up-to-date data is used and should be customised to the needs of the application.
With Redis as a locally installed cache - or even as a Docker container - and the right cache hierarchy, scalable and high-performance applications can be implemented.

DEMO:

Github: HybridCache

Implementing the Cached Repository Pattern in C#

Ben Witt — Tue, 23 Jul 2024 08:00:00 +0000

Introduction to the Concept of a Cached Repository

A cached repository is a design pattern aimed at enhancing application performance by storing data in a fast-access memory area known as a cache. This reduces the number of database accesses, thereby improving response times and the application's scalability. A repository abstracts data access and provides uniform interfaces for CRUD operations (Create, Read, Update, Delete). Combining these concepts offers a powerful method for optimizing data access patterns in modern applications.

Importance and Benefits of Using Cached Repositories in C# for Advanced Developers

For advanced developers, cached repositories offer several advantages:

Performance Improvement: Reducing database accesses significantly enhances response times.
Scalability: Lower database load facilitates better application scalability.
Cost Reduction: Fewer database queries translate to lower costs, especially with cloud services billed per query.
Consistency and Abstraction: Using a uniform repository ensures consistent data access and allows for easy abstraction and testing.

Detailed Implementation of a Cached Repository in C# Using the Decorator Pattern and EF Core

Implementing a cached repository can be effectively achieved through the decorator pattern. This pattern allows additional functionality to be added to an object without altering its structure.

Define the Repository Interface

public interface IProductRepository
{
    Task<Product> GetProductByIdAsync(int id);
    Task<IEnumerable<Product>> GetAllProductsAsync();
    Task AddProductAsync(Product product);
    Task UpdateProductAsync(Product product);
    Task DeleteProductAsync(int id);
}

Implement the Base Repository with EF Core

public class ProductRepository : IProductRepository
{
    private readonly ApplicationDbContext _context;

    public ProductRepository(ApplicationDbContext context)
    {
        _context = context;
    }

    public async Task<Product> GetProductByIdAsync(int id)
    {
        return await _context.Products.FirstOrDefaultAsync(x => x.Id == id);
    }

    public async Task<IEnumerable<Product>> GetAllProductsAsync()
    {
        return await _context.Products.ToListAsync();
    }

    public async Task AddProductAsync(Product product)
    {
        await _context.Products.AddAsync(product);
        await _context.SaveChangesAsync();
    }

    public async Task UpdateProductAsync(Product product)
    {
        _context.Products.Update(product);
        await _context.SaveChangesAsync();
    }

    public async Task DeleteProductAsync(int id)
    {
        var product = await _context.Products.FindAsync(id);
        if (product != null)
        {
            _context.Products.Remove(product);
            await _context.SaveChangesAsync();
        }
    }
}

Implement the Cached Repository

public class CachedProductRepository : IProductRepository
{
    private readonly IProductRepository _repository;
    private readonly IMemoryCache _cache;
    private readonly TimeSpan _cacheDuration = TimeSpan.FromMinutes(5);

    public CachedProductRepository(IProductRepository repository, IMemoryCache cache)
    {
        _repository = repository;
        _cache = cache;
    }

    public async Task<Product> GetProductByIdAsync(int id)
    {
        string cacheKey = $"Product_{id}";
        if (!_cache.TryGetValue(cacheKey, out Product product))
        {
            product = await _repository.GetProductByIdAsync(id);
            if (product != null)
            {
                _cache.Set(cacheKey, product, _cacheDuration);
            }
        }
        return product;
    }

    public async Task<IEnumerable<Product>> GetAllProductsAsync()
    {
        const string cacheKey = "AllProducts";
        if (!_cache.TryGetValue(cacheKey, out IEnumerable<Product> products))
        {
            products = await _repository.GetAllProductsAsync();
            _cache.Set(cacheKey, products, _cacheDuration);
        }
        return products;
    }

    public async Task AddProductAsync(Product product)
    {
        await _repository.AddProductAsync(product);
        InvalidateCache();
    }

    public async Task UpdateProductAsync(Product product)
    {
        await _repository.UpdateProductAsync(product);
        InvalidateCache();
    }

    public async Task DeleteProductAsync(int id)
    {
        await _repository.DeleteProductAsync(id);
        InvalidateCache();
    }

    private void InvalidateCache()
    {
        _cache.Remove("AllProducts");
    }
}

Best Practices and Potential Pitfalls in Using Cached Repositories in C#

Best Practices:

Cache Invalidation: Ensure the cache is invalidated after write operations (Add, Update, Delete) to maintain consistency.
Cache Duration: Choose an appropriate cache duration to balance freshness and performance.
Memory Management: Avoid overloading the cache, especially in memory-intensive applications.

Potential Pitfalls:

Stale Data: Cached data can become outdated, leading to inconsistencies.
Complexity: Implementing and managing cached repositories increases codebase complexity.
Memory Consumption: Excessive caching can lead to high memory usage and potential out-of-memory issues.

Comparison with Other Caching Strategies and Their Applications

In addition to the decorator pattern for cached repositories, there are several other caching strategies:

In-Memory Caching: Direct use of in-memory data stores like IMemoryCache or ConcurrentDictionary. Ideal for short-term, small data sets.
Distributed Caching: Use of distributed caches like Redis or Memcached. Suitable for applications with high scalability requirements.
HTTP Caching: Use of HTTP headers to cache web resources. Ideal for high-traffic web applications.

Each strategy has specific use cases and challenges that need to be carefully evaluated.

Advanced Topics: Cache Invalidation and Synchronization Between Cache and Database

Cache invalidation and synchronization are complex topics that require special attention:

Cache Invalidation:

Time-to-Live (TTL): Set a TTL for cache entries to ensure automatic invalidation.
Event-Based Invalidation: Use events or message queues to synchronize cache invalidations in distributed systems.

Synchronization Between Cache and Database:

Write-Through Caching: Write operations are performed on both the database and the cache, ensuring consistency.
Write-Behind Caching: Write operations are initially performed on the cache and later synchronized with the database. This can improve performance but carries the risk of data inconsistency in the event of a crash.
Cache Priming: Preload frequently accessed data into the cache at application startup to avoid initial latencies.

A comprehensive understanding and correct implementation of these techniques are crucial for successfully leveraging cached repositories in demanding applications.

In summary, cached repositories, combined with the decorator pattern and Entity Framework Core, offer an effective method for optimizing data access patterns. They provide significant performance benefits but require careful implementation and management to avoid potential pitfalls.

Github:
https://github.com/WittBen/CachedRepository

Artificial Intelligence with ML.NET for text classifications

Ben Witt — Tue, 16 Jul 2024 08:00:00 +0000

Recently, Artificial Intelligence (AI) has been gaining popularity at breakneck speed.
OpenAI’s ChatGPT was a breakthrough in Artificial Intelligence, and the enthusiasm was huge.
ChatGPT triggered a trend towards AI applications that many companies followed.
You read and hear about AI everywhere. Videos and images of celebrities performing strange dance moves appear, or you hear interviews and songs by artists who have “actually” been dead for several years.
The exact functioning of Artificial Intelligence will be explained below. As developers, we are used to thinking in categories and breaking problems down into small steps, and this is exactly how all Artificial Intelligence works. They are based on so-called models that have been trained for their respective areas of application.
Example:
If you ask ChatGPT for a picture, a separate model such as DALL-E must be used.
If you ask for a poem, ChatGPT uses a language model.
ChatGPT is nothing more than a ChatBot that uses different models for the task at hand.
This is where I would like to start and program a small Artificial Intelligence that classifies a customer review, which is available as free text, as positive or negative.
As a .NET developer, Microsoft offers a low-threshold entry into the world of machine learning with ML.NET. This free open-source framework makes it easy to integrate ML models into new and existing .NET applications — without any knowledge of Python, R, or other ML libraries. ML.NET already contains many ready-made models for common use cases and can be easily integrated into the existing .NET app lifecycle.
Basics of machine learning
The term “machine learning” describes the approach of teaching computers to learn patterns and relationships from data instead of explicitly programming them with rules and program logic. The aim is to enable the machine to “learn” independently from sample data and apply this knowledge to solve similar problems.
There are essentially three types of learning:

Supervised learning

Supervised learning is a method of machine learning in which a model is provided with training data consisting of input data (e.g. texts) and the corresponding desired outputs (e.g. classifications such as ‘positive’ or ‘negative’). Using these examples, the system learns to recognize patterns that relate the inputs to the outputs. This enables it to later predict correct outputs for new, unseen inputs. A classic application example is object recognition in images.

Example:
An application example for supervised learning with ML.NET could be the classification of product reviews as ‘positive’ or ‘negative’. The procedure would be as follows:



// Loading the training data with reviews and labels
var data = mlContext.Data.LoadFromTextFile<ReviewData>(pathToFile);
// Creating the processing pipeline
var pipeline = mlContext.Transforms.Text.FeaturizeText("ReviewText", "Features")
                        .Append(mlContext.BinaryClassification.Trainers.SdcaLogisticRegression("Label"));
// Training the model            
var model = pipeline.Fit(data);

At this point, we have a trained model that can classify new reviews.

Unsupervised learning

Unsupervised learning is a machine learning approach in which the model is only provided with unlabelled input data, e.g. text or images, without any associated target variables or classifications. The system must independently recognize structures, patterns, and correlations in this raw data. A typical area of application is clustering, in which similar input data is summarised into groups. Possible examples are the identification of customer segments based on marketing data or the grouping of news articles according to subject areas when analyzing text.
Example:
Unsupervised learning can be used with ML.NET for text clustering, for example:



// Loading the text data
var data = mlContext.Data.LoadFromTextFile<ArticleData>(pathToFile);
// Create the text featurisation pipeline
var pipeline = mlContext.Transforms.Text.FeaturizeText("ArticleText", "Features");
// Train the clustering model
var model = mlContext.Clustering.Trainers.KMeans(pipeline, numberOfClusters: 5).Fit(data);
// Predict the cluster membership for new articles
var predictions = model.Transform(data);

In this way, for example, news articles can be automatically categorized into thematic clusters such as politics, business, sports, etc.
ML.NET focuses mainly on supervised and partially unsupervised learning. ML.NET does not currently offer any specific support for reinforcement learning, in which an AI is trained through rewards in a simulated environment. This learning paradigm is used in particular for strategy-finding tasks, such as games or the optimization of processes.

Reinforcement Learning

Reinforcement learning is a learning paradigm in which Artificial Intelligence is trained by trial and error in a simulated environment. In contrast to supervised learning, there are no complete training examples with input-output pairs. Instead, the system receives a score (reward) for each action, which indicates how “good” this action was. By maximizing the accumulated rewards, the AI learns to find the optimal strategy for a task. This principle of reinforcement learning is used in particular for tasks that require a complex strategy to be found. Examples include board games such as chess or Go, but also applications for robot control, process optimization, or autonomous driving.

Example:
A classic application example is a chess player agent. Here the environment could be a chessboard, possible actions are move movements. The agent then receives an evaluation for each move, e.g. +1 for a sure pawn win, -5 for an impending piece loss. Through many training games, the AI learns which moves to lead to a win in the long term and thus maximizes its cumulative reward.
Set up the development environment
To get started with ML.NET, we need the .NET Core or .NET Framework environment in version 4.6.1 or higher. ML.NET can be used in Visual Studio, Visual Studio Code, or the command line.

The first step is to install the required NuGet packages of ML.NET:



Install-Package Microsoft.ML

This main package contains basic functionality such as the ML.NET context, data transformations, and catalogs with models and tasks. For additional functionality, other packages such as Microsoft.ML.Vision for image processing or Microsoft.ML.Recommender for recommender systems can be added.
After installation, we can create a .NET Core or .NET Framework console application in Visual Studio and start development.
Optionally, integrated tools such as the Model Builder interface in Visual Studio or the ML.NET CLI can be used to visualize data and create models. I’ll come back to this later.

Creating the first ML model

In the following, the basic concepts of ML.NET are explained step by step using an example:
The classification of customer reviews is based on free text.
The result should be to categorize these ratings as positive or negative.
This is a classic supervised learning problem.
We create a new C# console application and import the ML.NET NuGet packages.
Next, we load the data set into the working memory. In our example, we need a TSV (tab-separated file) file for this. This is represented by a simple class in our console application:
This class stands for each line within the TSV file.



public class ReciewData
{
}

Now we add properties for each column of the TSV data:



public class ReviewData   
{    
 public string ReviewText { get; set; }    
 public bool Label { get; set; }   
}

Unfortunately, this is not enough to load this TSV file and teach ML.Net how to reference this file.
We need attributes for this: LoadColumn plus the index of the column.



public class ReviewData
{
  [LoadColumn(0)]
  public string ReviewText { get; set; }

 [LoadColumn(1)]
  public bool Label { get; set; }
}

This is a simple mapping from the ReviewText property to the TSV file ReviewText column.
Now let’s take care of the storage paths for the files and save them in our application:
First, we create the path to our training file, the TSV file (Review.tsv).



string baseDirectory = @"..\..\AI"; 
string subDirectory = "TrainingData";

string trainingDataFilePath = Path.Combine(baseDirectory, subDirectory, "Reviews.tsv");

We will use this file to train the model that we want to use for classification.
Now we define the path to the model that we want to train. This model is saved as a ZIP file.



string modelPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "model.zip");

Now we need a variable for our MLContext. The MLContext is comparable to an EF DbContext. So, whenever you want to work with machine learning, you have to interact with the MLContext, similar to the DBContext in EF Core.
Now we are ready to load the data. We can manipulate it as we need it to train the model according to our requirements.
Now we build our model:
For this, we need a specific type from ML.NET. The IDataView:



var trainingDataView = mlContext.Data.LoadFromTextFile<ReviewData>(trainingDataFilePath, separatorChar: '\t', hasHeader: true);

Here I can now use a function from the MLContext called LoadFromTextFile. <ReviewData> is now used to project the data into our initially created class. The path to the training file must now be passed to this function. As a bonus, we can specify further options here, such as the separator from the TSV file and whether our training file has a header or not (we have a header, so I set this parameter to true).
Now that we have loaded the data into a DataView, we can start preprocessing. Preprocessing is a means of creating what is called a pipeline. This can later be used to perform predictions when we have incoming data (e.g. our customer score). To do this, we need to extract the data from the data view we have created (IDataView) and then transform it so that it can be used as part of the machine-learning process.

Now let’s create our pipeline. This has a specific return type: IEstimator:



/// <summary>
/// Creates the machine learning pipeline for review classification.
/// </summary>
/// <param name="context">The ML context.</param>
/// <returns>The machine learning pipeline.</returns>
public static IEstimator<ITransformer> CreatePipeline(MLContext context)
{
  return context.Transforms.Text.FeaturizeText("Features", "ReviewText")
      .Append(context.BinaryClassification.Trainers.SdcaLogisticRegression(labelColumnName: "Label"))
      .AppendCacheCheckpoint(context);
}

Context.Transforms.Text.FeaturizeText is a text transformation component in ML.NET that is used to convert text data into numerical features.
“Features” is the new column name that contains the resulting numerical characteristics.
„ReviewText” is the name of the column from the TSV file that contains the text to be converted into numerical characteristics.
Now the training of the model begins:
.Append adds the next step to the pipeline. The model is trained with Context.BinaryClassification.Trainers.SdcaLogisticRegression, which defines the algorithm with which the model is to be trained — in this case the SdcaLogisticRegression algorithm. “Label” is the column or the name of the column that represents the target variable to be predicted. In our example, it is the classification of whether this evaluation is positive or negative.

Let’s summarise this again:

This command builds a pipeline that performs the following steps:
text featurisation: the text from the “ReviewText” column is converted into numerical features and stored in the new “Features” column.
model training: The numerical features in the “Feature” column are used to train a binary classification model with the target variable in the “Label” column.
Now we have created our pipeline and can start training the model.



var pipeline = CreatePipeline(mlContext);
var model = pipeline.Fit(trainingDataView);

We use the pipeline.Fit(…) command to train the model on the data from the TSV file. The model is then stored in memory.
However, to save the model and not have to create and retrain it each time, we can use the Save() method. This allows us to save the trained model in a specific file path. In this way, we can simply load and use the model when needed without having to retrain it each time.
There is an option in MlContext where we can find the Save() function:



context.Model.Save(model, schema, modelPath);

Firstly, we transfer the trained model and the schema from the IDataView from the TSV file, and then the path where we want to save the model.

We have now trained our model and saved it to the hard disc.
Now we need another class that represents the trained DataSet, i.e. the results from our model (prediction class). To do this, we create another class that has a similar structure to the class for the DataSet from the TSV file (ReviewData).



public class ReviewPrediction
  {
    [ColumnName("PredictedLabel")]
    public bool PredictedLabel { get; set; }
  }

The attribute defines that the name of the “PredictedLabel” column is to be used in the MLContext to read the predicted value there.

To connect the model to the prediction class, we now need a PipelineEngine. We create this engine again from the MLContext.



var predictionEngine = mlContext.Model.CreatePredictionEngine<ReviewData, ReviewPrediction>(model);

We use the generic types TSrc (Source) and TDst (Destination) for our input and output classes, “ReviewData” and “ReviewPrediction” (“Good rating”, “Positiv”).

The individual components and their interaction should now be understandable:
Why we need to convert texts into numerical features, why we need to prepare data so that the computer can understand it, and that our “ReviewData” class is our source class and “ReviewDataPrediction” is our target class.

Now that we have completed the preparation steps, we can move on to the prediction phase.
Let’s now take care of the code that performs the prediction and returns the expected target variable.
In our example, the predicted result is a Boolean value.

The first step is to enter a score, which we then write to our “ReviewData” input class.



var input = new ReviewData { ReviewText = inputReviewText };

The variable “ReviewText” is a string variable that contains our review.
We now pass this input variable of type “ReviewData” to the pipeline that we have just created.
As a result, we receive our “ReviewPrediction” output class and can now access the target variable from the model via the variable.



// Classify the new rating and display the result
var prediction = predictionEngine.Predict(input);
Console.WriteLine($"The classification for the rating ‘{ input.ReviewText}’ is: { (prediction.PredictedLabel ? "Positiv" : "Negativ")}");

If the model had good training data, we should now get the correct predicted results.

It seems to work.

Of course, this is only a small example, and the model is not perfect, but if you train it well, it should ideally always return correct results.
The following extensions have been added to the example to retrain the model if inputs were incorrect or unknown.
When starting the application, you can choose between adding new data to the model and direct training or you can create new comments.
In the following article, I will take a closer look at image recognition and prediction.

Summary:

Although this article is limited to text classification, on closer inspection, and with a little creativity, the approach described opens up numerous possibilities. For example, the recognition of a certain classification could be used to trigger further processes automatically.
Overall, it can be said that Artificial Intelligence has enormous potential to support us in many areas of everyday life and to optimize processes. Text classification is just one example of the many possible applications. It can be assumed that more and more areas will benefit from the possibilities of AI in the future and that this will open up new opportunities for companies and private individuals alike.
To fully exploit this potential, it is important that we are open to new technologies and that we address the possibilities and limitations of AI. This is the only way we can ensure that Artificial Intelligence is used responsibly and for the benefit of all in the future.

Github:
https://github.com/WittBen/AIUnderCSharp

Links:
ML.wNET | Machine learning made for .NET
What is ML.NET and how does it work? — ML.NET

The Chain of Responsibility

Ben Witt — Tue, 09 Jul 2024 08:00:00 +0000

The essence of the Responsibility of Chain pattern:

The Chain of Responsibility pattern is a design pattern that allows code to be structured to route requests through a series of handlers. Each handler has the ability to process a request or pass it on to the next handler in the chain. This flexibility facilitates the handling of complex requests in a modular and scalable way.

The basics in detail:

To fully grasp the pattern, an understanding of how it works is necessary. Here we will highlight the mechanism of the responsibility-of-chain pattern and compare it to other common approaches such as if-else statements to highlight its strengths and potential uses.

Implementation in C#:

Now let’s get down to business and implement the pattern in C#. Step by step, we will be guided through the creation of handler classes, their linking to a chain and the handling of requests through this chain.

Practical application:

To reinforce what we have learned, we present a practical example. Here we illustrate the pattern using a concrete scenario, show its implementation and carry out tests to demonstrate its effectiveness.

Advanced concepts and subtleties:

Looking outside the box reveals advanced concepts and optimizations of the Responsibility of Chain pattern. We discuss ways to improve the implementation, the dynamic adaptation of the chain at runtime as well as effective error handling and traceability.

Summary:

Finally, we summarize the key points and give advice for further deepening and applying the Chain of Responsibility pattern in your own projects.
Ready to unleash the power of the Chain of Responsibility pattern? Then let’s dive into the world of responsibility chains together and take your C# development to a new level.

What is the Chain of Responsibility pattern?

The Chain of Responsibility pattern, an established design pattern in software development, acts as a proven tool for the efficient processing of requests or events. Its strength lies in the elegant decoupling of the requester from the recipients by providing a dynamic chain of potential recipients. Each recipient in this chain is able to decide independently whether it can handle the request adequately or forward it appropriately to the next recipient. This flexible structure ensures effective and modular processing of requests, which significantly improves both the maintainability and extensibility of software solutions.

Purpose of the pattern:

Decoupling of sender and recipient: The Chain of Responsibility pattern enables a clean separation between the sender of a request and the potential recipients. This avoids the need for the sender to have specific knowledge about the recipients, as the responsibility for processing the request lies within the chain.

Flexibility and expandability:

By structuring it as a chain of recipients, the template offers a high degree of flexibility when adding new recipients or changing existing ones. These changes can be made without modifying the sender, which significantly improves the maintainability and expandability of the system.

Avoidance of hard-coded dependencies:

The Chain of Responsibility pattern helps to avoid rigid dependencies by allowing the handling of requests to be configured dynamically. This means that the system remains open to change and can adapt to changing requirements without being tied to specific implementations.

Advantages of the pattern:

Improved maintainability: The clear separation of sender and recipient leads to code that is easier to understand and maintain. This level of abstraction makes the code base cleaner and less prone to unexpected side effects during maintenance.
Extensibility: Adding new recipients or changing the order of existing recipients is straightforward, as this can be done without making any adjustments to the sender. This keeps the code base flexible and open for future adaptations or extensions.
Decoupling: The individual components of the system are loosely coupled thanks to the Chain of Responsibility pattern. This enables improved reusability and testability of the components, as they can be developed, tested and maintained independently of each other.
Use cases:
Processing of requests: The pattern is ideal for processing requests in different scenarios. For example, it could be used in an e-commerce application to validate payment methods depending on various criteria, such as the amount of the purchase or the selected currency.
Event handling: In a GUI framework, the Chain of Responsibility pattern can be used to process user interactions efficiently. Different components within the chain can respond to events such as mouse clicks or keystrokes, ensuring flexible and scalable handling of user actions.
The pattern thus proves to be an extremely versatile tool for structuring complex processing logic in a wide variety of application areas, which can significantly increase the flexibility and maintainability of software systems.

Understand the basics:

In order to understand the The Chain of Responsibility pattern in depth, it is crucial to penetrate the fundamental workings of the pattern and relate them to other approaches. Such an understanding makes it possible to fully appreciate the strengths and potential of this design pattern.
The The Chain of Responsibility pattern operates on the basis of a hierarchical sequence of handlers that receive a request and either handle it themselves or pass it on to the next handler in the chain. This process of processing takes place in turn until the request is successfully processed or the chain is exhausted.
A key point of comparison is the contrast with other common approaches such as the use of if-else statements. While the latter represent a sequential and static decision structure in which each condition is explicitly defined in the code, the responsibility-of-chain pattern offers a dynamic and flexible alternative.
By using a chain of handlers, the pattern enables an elegant decoupling of the sender from the receivers, creating a loosely coupled architecture. This level of abstraction not only facilitates the maintenance and extension of the code, but also promotes the reusability of the individual components.
Overall, the Chain of Responsibility pattern enables efficient processing of requests or events in complex systems by providing a flexible and extensible structure. An in-depth understanding of how it works and a comparison with other approaches are therefore essential in order to recognize its full potential and make optimal use of it.

How does the Chain of Responsibility pattern work?

The Chain of Responsibility pattern is divided into three main components that form the framework for its functionality:
1. Handler (recipient): Each handler embodies a potential recipient of a request or event. This component implements a method or interface for processing the request. If a handler is unable to handle the request, it forwards it to the next handler in the chain. This flexible structure makes it possible to dynamically distribute responsibility for the request between the handlers, depending on the specific requirements of the system.
2. Chain: The chain forms the structural basis of the pattern and consists of a series of handlers that are linked together. Each handler in the chain references the next handler, creating a sequential order. In this way, the request can be passed through the chain until a suitable handler is found that can process it successfully. This flexible forwarding functionality enables efficient and modular handling of requests in complex systems.
3. Client (sender): The client initiates the request process by creating a request and passing it to the first handler in the chain. An important feature of the pattern is that the client does not need to be aware of the specific handling of the request. This abstraction layer enables a clean separation between client and receivers, which increases the flexibility and maintainability of the system.
Through the interaction of these three main components, the Chain of Responsibility pattern enables elegant and flexible handling of requests or events in complex software systems. It promotes the reusability, extensibility and maintainability of the code by providing a clear and modular structure that allows the processing logic to be easily adapted and extended.

Comparison with other patterns:

A frequent comparison between the Chain of Responsibility pattern and the use of if-else statements shows clear differences:
If-Else statements: The request processing logic is embedded directly in the sender. This can lead to confusing and difficult to maintain code, especially with many conditions. Adding new conditions often requires changes to the sender, which makes maintenance more difficult.
Chain of Responsibility pattern: Here the processing logic is encapsulated in separate handler classes that are connected in a chain. The sender only has to send the request to the beginning of the chain without having to worry about the details of request processing. This promotes modularity and flexibility in the code.
Example:
To illustrate the concept of the Chain of Responsibility pattern, let’s look at a simple example from the field of authentication:
Suppose we have a chain of authentication checks that must be run in sequence:

checking user authorizations.
checking the validity of the password.
verification of two-factor authentication . In this scenario, each check is represented as a handler in the chain. If a check fails, the request is forwarded to the next handler in the chain. This structure allows for flexible and extensible authentication logic, as new checks can easily be added or the order changed without changing the main authentication mechanism. Summary: The Chain of Responsibility pattern presents an elegant solution for forwarding requests or events through a chain of handlers. This makes the code more flexible, maintainable and extensible. In the next section, we will take a closer look at the implementation of this pattern in C#. Step 1: Creating the handler classes for support staff We create handler classes for processing support requests.

public abstract class SupportHandler
{
  protected SupportHandler NextHandler;
  public void SetNextHandler(SupportHandler handler)
  {
    NextHandler = handler;
  }
  public abstract void HandleRequest(SupportRequest request);
}
public class Level1SupportHandler : SupportHandler
{
  public override void HandleRequest(SupportRequest request)
  {
    // Verifying if Level-1 support can handle the request
    if (/* Condition for successful processing */)
    {
      Console.WriteLine("Support request successfully processed by Level-1 support.");
    }
    else if (NextHandler != null)
    {
      // Forwarding request to the next handler
      NextHandler.HandleRequest(request);
    }
    else
    {
      Console.WriteLine("No support personnel could handle the request.");
    }
  }
}

Step 2: Linking the handlers to a chain

// Similarly, implement the other handler classes for level 2 support, level 3 support, etc.

//We create a chain of support staff.
public class SupportChain
{
  private SupportHandler _firstHandler;
  public SupportChain()
  {
    // The order of the handlers is defined here
    _firstHandler = new Level1SupportHandler();
    _firstHandler.SetNextHandler(new Level2SupportHandler());
    _firstHandler.SetNextHandler(new Level3SupportHandler());
    // Further handlers can be added here
  }
  public void ProcessSupportRequest(SupportRequest request)
  {
    // Send request to the beginning of the chain
    _firstHandler.HandleRequest(request);
  }
}

Step 3: Processing support requests through the chain

//We use the created chain to process support requests.
public class SupportClient
{
  public void ProcessSupport()
  {
    SupportChain chain = new SupportChain();
    SupportRequest request = new SupportRequest(/* Details of the support request */);
    chain.ProcessSupportRequest(request);
  }
}

In this example, support requests are routed through a chain of support employees. Each employee checks whether they can process the request and forwards it to the next employee if necessary. This structure enables efficient processing of support requests and facilitates the expansion of the system with additional support levels or functions.
Practical example:
To further illustrate the responsibility-of-chain pattern, we will now implement a simple practical example. In this scenario, we will create an application to handle customer support requests.
In this application, support requests are routed through a chain of support employees. Each employee checks whether they can process the request and forwards it to the next employee if necessary. This enables efficient processing of support requests and easy expansion of the system with additional support levels or functions.
Scenario:
For our application, we plan to receive support requests from customers and forward them to different support levels according to their urgency. The support employees are to be organized in a chain, with each employee having the option of processing the request or forwarding it to the next employee in the chain.
To implement this, we need to:

create a chain of support agents.
each employee in the chain should have a method to handle a support request or pass it on to the next employee.
the application should provide a way to receive support requests and forward them to the first employee in the chain. By implementing this scenario, we will see the Responsibility of Chain pattern in action and how it provides an efficient and flexible solution for handling support requests. Implementation: We will carry out the implementation in C#.

// Definition of the support request
public class SupportRequest
{
  public string CustomerName { get; set; }
  public string RequestDetails { get; set; }
  public int Priority { get; set; }
  // Further relevant properties can be added here
}

// Abstract handler class for support agents
public abstract class SupportHandler
{
  protected SupportHandler NextHandler;
  public void SetNextHandler(SupportHandler handler)
  {
    NextHandler = handler;
  }
  public abstract void HandleRequest(SupportRequest request);
}

// Handler class for level 1 support
public class Level1SupportHandler : SupportHandler
{
  public override void HandleRequest(SupportRequest request)
  {
    if (request.Priority <= 3) // Example priority check
    {
      Console.WriteLine($"Support request from {request.CustomerName} processed by level 1 support.");
    }
    else if (NextHandler != null)
    {
      NextHandler.HandleRequest(request);
    }
    else
    {
      Console.WriteLine("No support agent was able to process the request.");
    }
  }
}

// Handler class for level 2 support
public class Level2SupportHandler : SupportHandler
{
  public override void HandleRequest(SupportRequest request)
  {
    if (request.Priority <= 6) // Example priority check
    {
      Console.WriteLine($"Support request from {request.CustomerName} processed by level 2 support.");
    }
    else if (NextHandler != null)
    {
      NextHandler.HandleRequest(request);
    }
    else
    {
      Console.WriteLine("No support agent was able to process the request.");
    }
  }
}

// Handler-Klasse für Level-3-Support
public class Level3SupportHandler : SupportHandler
{
  public override void HandleRequest(SupportRequest request)
  {
    // Level-3-Support bearbeitet alle Anfragen, da es die letzte Ebene ist
    Console.WriteLine($"Supportanfrage von {request.CustomerName} vom Level-3-Support bearbeitet.");
  }
}

// Implementation of the clients
public class SupportClient
{
  public void ProcessSupportRequest(SupportRequest Anfrage)
  {
    SupportHandler chain = new Level1SupportHandler();
    chain.SetNextHandler(new Level2SupportHandler());
    chain.SetNextHandler(new Level3SupportHandler());
    chain.HandleRequest(request);
  }
}

Application of the example:
Now we can use our example to process requests:

class Program
{
  static void Main(string[] args)
  {
    SupportClient client = new SupportClient();
    // Create example request
    SupportRequest request = new SupportRequest
    {
      CustomerName = "John Doe",
      RequestDetails = "I am facing issues with my account login.",
      Priority = 5 // Example priority
    };
    // Process request
    client.ProcessSupportRequest(request);
  }
}

Result:
Depending on the priority of the request, it is forwarded to the appropriate support level and processed accordingly. The Chain of Responsibility pattern enables flexible and scalable handling of support requests in a customer support system.
Advanced concepts and optimizations:
After looking at the basic understanding of the Chain of Responsibility pattern and its implementation in C#, we can turn to advanced concepts and optimizations to improve our solution. These include efficient chain traversal strategies, dynamic configuration of the support chain, improvements in error handling and optimization of resource usage. These measures help to increase the performance, efficiency and robustness of our application to meet the needs of our users.
Dynamic Chain Adjustment at Runtime:
One way to enhance the flexibility of our system is by dynamically adjusting the chain of support agents at runtime. This entails the ability to modify the order or composition of support agents as needed without altering the code.
Through this dynamic adjustment, we can, for instance, add new support tiers, replace existing agents, or alter the prioritization of agents in the chain, all without the necessity of modifying the source code. This endows our system with high flexibility and adaptability to changing requirements or business scenarios.
By implementing this dynamic adjustment, we can ensure that our support system consistently responds optimally to our customers’ needs, ensuring efficient handling of support inquiries even in rapidly changing environments.

public class SupportClient
{
  private SupportHandler _chain;
  public SupportClient(SupportHandler initialHandler)
  {
    _chain = initialHandler;
  }

  public void SetSupportChain(SupportHandler handler)
  {
    _chain = handler;
  }

  public void ProcessSupportRequest(SupportRequest request)
  {
    _chain.HandleRequest(request);
  }
}
  public void ProcessSupportRequest(SupportRequest request)
  {
    _chain.HandleRequest(request);
  }
}

Implementation of a Dynamic Support Chain Adjustment Mechanism:
By implementing a mechanism for dynamically adjusting the support chain, the application can flexibly respond to changes in the support process without requiring modifications to the source code. This facilitates the adaptation of the support structure as needed, allowing for the addition of new support tiers, replacement of existing staff, or reordering of staff members. This approach ensures that the application remains agile and adaptable to meet evolving requirements and business scenarios.
Error Handling and Traceability:
Another crucial consideration is error handling and traceability within the chain. It is essential for the application to handle errors appropriately and provide the capability to trace the processing status of requests.

public abstract class SupportHandler
{
  // …
  public virtual void HandleRequest(SupportRequest request)
  {
    try
    {
      // Processing of the Request
    }
    catch (Exception ex)
    {
      Console.WriteLine($"Error occurs during the process: {ex.Message}");
    }
  }
}

By implementing error handling in each handler, we can ensure that the application is resilient against unexpected errors. Furthermore, we can add traceability mechanisms, such as logging or appending additional information to the request.
Further Optimizations:

Implementation of mechanisms for parallel processing of requests in the chain to enhance performance.
Use of Dependency Injection for easier configuration of the support chain and improved testability.
Implementation of mechanisms for automatic adjustment of support priorities based on specific criteria. Considering these advanced concepts and optimizations allows us to further enhance the flexibility, performance, and robustness of our system. In this tutorial, we extensively covered the Chain of Responsibility pattern in C#. We explained its purpose, how it works, and its implementation through a practical example. Additionally, we examined advanced concepts and optimizations to improve the performance and flexibility of our solution. With this understanding, we are now able to effectively utilize the Chain of Responsibility pattern in our own projects and develop robust, flexible applications. Summary:
The Chain of Responsibility pattern allows requests or events to be passed through a chain of handlers, with each handler having the ability to process the request or pass it to the next handler.
Using this pattern enables the separation of sender and receiver, leading to more flexible, maintainable, and extensible code.
Implementing the pattern in C# involves creating handler classes and linking them to form a chain that processes requests.
Advanced concepts such as dynamic adjustment of the chain at runtime and error handling enhance the flexibility and robustness of our solution. Conclusions: The Chain of Responsibility pattern is undeniably a powerful tool in software development that can be employed in numerous application domains to structure complex processing logic. Through careful implementation and consideration of advanced concepts, we can develop flexible, robust, and high-performing systems. Applying this pattern enables clean separation of concerns, increased maintainability and extensibility of the code, and improved responsiveness to changing requirements. By mastering the principles of the Chain of Responsibility pattern and fully harnessing its potential, we can develop software solutions that meet the highest standards in terms of flexibility, robustness, and performance.

Forem: Ben Witt

Transitive Dependency – Challenges and Approaches in .NET

1. Basics and Problem Statement

1.1 Transitive References vs. Transitive Dependencies

1.2 A Typical Scenario in .NET

2. Detailed Solution Approaches

2.1 PrivateAssets="all"

2.2 DisableTransitiveProjectReferences

2.3 Comparison of Both Approaches

3. Practical Example: Abstraction and Interface Encapsulation

4. Advanced Strategies and Alternative Approaches

5. Summary and Outlook

Efficient Debugging and Precise Logging in C#: Using Caller Attributes

Basics of the Attributes

Code Examples for Practical Applications

Practical Application with a Library Management System

Limitations and Best Practices

Conclusion

A Critical Look at Cancellation Management in .NET Applications

Asynchronous HTTP Requests – Explained Simply

WPF Application with Plugin Architecture

Overview over the structure

The plug-in interface

Implementation of a plug-in

Dynamic loading and registration of plug-ins

Automatic registration of views and ViewModels with Autofac

Communication between plug-ins via the EventAggregator

Conclusion

HealthChecks

DBConcurrency with EF Core

What is concurrency in the database?

Why is concurrency control important?

Conflict detection in Entity Framework Core

„Timestamp” attribute:

„ConcurrencyCheck“ attribute:

Strategies for conflict resolution

Implementation of concurrency control in a sample application

Conflict simulation:

Basics of Clean Architecture with C#

Introduction to Clean Architecture

The Principles of Clean Architecture

The Components of Clean Architecture

Implementing the Project Structure:

Implementing Entities:

Implementing Use Cases:

Implementing Interface Adapters:

Implementation of Clean Architecture in C

Testing in Clean Architecture

Test-Driven Development (TDD) Approach:

Conclusion:

HybridCache in a console application with Redis

What is a HybridCache?

Implementation of the HybridCache

Cache invalidation

When is which cache used?

Extended strategies for cache invalidation

Install Redis - locally or via Docker

Other options - e.g. with MS SQL Server

Conclusion

DEMO:

Implementing the Cached Repository Pattern in C#

Introduction to the Concept of a Cached Repository

Importance and Benefits of Using Cached Repositories in C# for Advanced Developers

Detailed Implementation of a Cached Repository in C# Using the Decorator Pattern and EF Core

Best Practices and Potential Pitfalls in Using Cached Repositories in C#

Comparison with Other Caching Strategies and Their Applications

Advanced Topics: Cache Invalidation and Synchronization Between Cache and Database

Artificial Intelligence with ML.NET for text classifications

Creating the first ML model

Summary:

The Chain of Responsibility

What is the Chain of Responsibility pattern?

How does the Chain of Responsibility pattern work?

2.1 `PrivateAssets="all"`