Forem: Hootan Hemmati

Learning - MassTransit Transactional Outbox Pattern

Hootan Hemmati — Sun, 30 Mar 2025 13:30:54 +0000

The Transactional Outbox pattern in MassTransit solves the critical problem of atomic operations between database transactions and message publishing in distributed systems. This learning document explores the pattern in depth, including its implementation in MassTransit, the differences between Bus Outbox and Consumer Outbox, and practical code examples.

Context

In our microservices architecture, we frequently need to update a database and publish events/messages atomically. Without a proper pattern, we risk data inconsistency if the application fails after the database transaction completes but before messages are published. The Transactional Outbox pattern ensures that database operations and message publishing occur reliably as a single unit of work.

Key Concepts

Transactional Outbox Pattern: A design pattern that ensures database operations and message publishing occur atomically
Bus Outbox: Captures messages published/sent within a scope and saves them to be delivered later
Consumer Outbox: Combines an inbox (for exactly-once processing) and outbox functionality
Message Broker Decoupling: Separates database transactions from message broker delivery
Exactly-once Processing: Guarantees messages are processed exactly once
Message Ordering: Preserves the order of messages as they were produced

Detailed Notes

Concept 1: The Problem - Atomic Operations Between Database and Message Broker

In distributed systems, it's common to need both database updates and message publishing to occur as an atomic operation. For example:

User places an order (data written to Orders database)
Order placement event is published for other services

However, traditional two-phase commit (2PC) between databases and message brokers should be avoided due to:

Poor performance
Complexity
Potential for distributed deadlocks
Limited support across different technologies

If we update the database first, then publish the message, a system failure between these steps would result in the data being updated but the message never being sent. Conversely, if we publish first, then update the database, a failure would result in a message being sent but the database never being updated.

Concept 2: The Transactional Outbox Pattern Solution

The Transactional Outbox pattern addresses this problem by:

Storing messages to be published in the same database transaction as the business data
Using a separate process to read these stored messages and publish them to the message broker
Tracking delivery status to ensure exactly-once processing

This approach provides:

Atomic operations between database and message publishing
Reliable message delivery even in case of failures
Preservation of message ordering
Decoupling of database transactions from message broker availability

Concept 3: MassTransit's Implementation - Bus Outbox

MassTransit's Bus Outbox works within a container scope (such as an ASP.NET Controller scope) and:

Intercepts calls to IPublishEndpoint and ISendEndpointProvider
Stores messages in the database via Entity Framework's DbContext
Uses a delivery service to read stored messages and publish them to the broker
Tracks message delivery state to ensure ordering and exactly-once delivery

The Bus Outbox flow:

Application code calls Publish() or Send()
Instead of going directly to the message broker, messages are stored in the OutboxMessage table
When SaveChangesAsync() is called on the DbContext, messages are committed with the transaction
A delivery service queries for new messages and delivers them to the broker
The OutboxState table tracks delivery state and provides locking for concurrent delivery services

Concept 4: MassTransit's Implementation - Consumer Outbox

The Consumer Outbox combines inbox and outbox functionality:

Inbox: Tracks received messages by MessageId to ensure exactly-once processing
Outbox: Stores published/sent messages until the consumer completes successfully

The Consumer Outbox flow:

As a message is received, it's locked in the inbox by MessageId
When the consumer publishes or sends messages, they're stored in the OutboxMessage table
Once the consumer completes successfully, the stored messages are delivered to the broker
After successful delivery, the received message is acknowledged

This ensures:

Exactly-once consumer execution
Reliable message publishing even if the consumer fails
Preservation of message order

Code Examples

Example 1: Configuring the Bus Outbox with SQL Server and Entity Framework Core

// Program.cs
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureServices((hostContext, services) =>
        {
            // Add DbContext
            services.AddDbContext<OrderDbContext>(options =>
                options.UseSqlServer(hostContext.Configuration.GetConnectionString("OrderDatabase")));

            // Configure MassTransit with the Outbox
            services.AddMassTransit(x =>
            {
                // Configure Entity Framework Core Outbox
                x.AddEntityFrameworkOutbox<OrderDbContext>(o =>
                {
                    // Configure the SQL Server Lock Statement
                    o.UseSqlServer();

                    // Configure Outbox to use SQL Server transport
                    o.UseBusOutbox();

                    // Query for ready messages every 5 seconds
                    o.QueryDelay = TimeSpan.FromSeconds(5);

                    // Optional: Further configuration
                    o.DuplicateDetectionWindow = TimeSpan.FromMinutes(30);
                });

                // Configure RabbitMQ (or your preferred transport)
                x.UsingRabbitMq((context, cfg) =>
                {
                    cfg.Host("localhost");
                    cfg.ConfigureEndpoints(context);
                });
            });

            // Add other services
            services.AddControllers();
        });

Example 2: Using the Bus Outbox in a Controller/Service

public class OrderController : ControllerBase
{
    private readonly OrderDbContext _dbContext;
    private readonly IPublishEndpoint _publishEndpoint;

    public OrderController(
        OrderDbContext dbContext,
        IPublishEndpoint publishEndpoint)
    {
        _dbContext = dbContext;
        _publishEndpoint = publishEndpoint;
    }

    [HttpPost]
    public async Task<IActionResult> PlaceOrder([FromBody] OrderRequest request)
    {
        // Create and save the order
        var order = new Order
        {
            CustomerId = request.CustomerId,
            ProductId = request.ProductId,
            Quantity = request.Quantity,
            OrderDate = DateTime.UtcNow
        };

        _dbContext.Orders.Add(order);

        // Create and publish the OrderPlaced event
        await _publishEndpoint.Publish<OrderPlaced>(new
        {
            OrderId = order.Id,
            order.CustomerId,
            order.ProductId,
            order.Quantity,
            order.OrderDate
        });

        // Save changes to the database and outbox in a single transaction
        await _dbContext.SaveChangesAsync();

        return Ok(new { OrderId = order.Id });
    }
}

Example 3: Configuring the Consumer Outbox

// Program.cs
services.AddMassTransit(x =>
{
    // Configure Entity Framework Core Outbox
    x.AddEntityFrameworkOutbox<OrderProcessingDbContext>(o =>
    {
        o.UseSqlServer();

        // Configure the Consumer Outbox
        o.UseConsumerOutbox();

        o.QueryDelay = TimeSpan.FromSeconds(5);
    });

    // Configure consumers
    x.AddConsumer<OrderProcessingConsumer>();

    x.UsingRabbitMq((context, cfg) =>
    {
        cfg.Host("localhost");

        // Configure the endpoint with outbox
        cfg.ConfigureEndpoints(context);
    });
});

Example 4: Using the Consumer Outbox in a Consumer

public class OrderProcessingConsumer : IConsumer<OrderPlaced>
{
    private readonly OrderProcessingDbContext _dbContext;
    private readonly ISendEndpointProvider _sendEndpointProvider;

    public OrderProcessingConsumer(
        OrderProcessingDbContext dbContext,
        ISendEndpointProvider sendEndpointProvider)
    {
        _dbContext = dbContext;
        _sendEndpointProvider = sendEndpointProvider;
    }

    public async Task Consume(ConsumeContext<OrderPlaced> context)
    {
        // Process the order
        var orderProcessing = new OrderProcessing
        {
            OrderId = context.Message.OrderId,
            Status = "Processing",
            ProcessedDate = DateTime.UtcNow
        };

        _dbContext.OrderProcessings.Add(orderProcessing);
        await _dbContext.SaveChangesAsync();

        // Send a command to the inventory service
        var sendEndpoint = await _sendEndpointProvider.GetSendEndpoint(
            new Uri("queue:inventory-service"));

        await sendEndpoint.Send<ReserveInventory>(new
        {
            OrderId = context.Message.OrderId,
            ProductId = context.Message.ProductId,
            Quantity = context.Message.Quantity
        });

        // No need to call SaveChangesAsync() again
        // Messages will be delivered after the consumer completes successfully
    }
}

Example 5: Creating the Entity Framework DbContext for the Outbox

public class OrderDbContext : DbContext
{
    public OrderDbContext(DbContextOptions<OrderDbContext> options) 
        : base(options)
    {
    }

    public DbSet<Order> Orders { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        // Configure your entity mappings here
        modelBuilder.Entity<Order>(entity =>
        {
            entity.HasKey(e => e.Id);
            entity.Property(e => e.CustomerId).IsRequired();
            entity.Property(e => e.ProductId).IsRequired();
            entity.Property(e => e.Quantity).IsRequired();
            entity.Property(e => e.OrderDate).IsRequired();
        });

        // The outbox tables will be configured automatically by MassTransit
    }
}

Application to Current Work

We can implement the Transactional Outbox pattern in our e-commerce microservices to ensure reliable order processing
This solves our current issue with occasional lost messages between the Order and Inventory services
The Bus Outbox is suitable for our API services that need to publish events after database updates
The Consumer Outbox is ideal for our background processing services that need to ensure exactly-once processing

Questions for Further Exploration

How does the Outbox pattern perform under high throughput scenarios?
What is the overhead in terms of database size and performance?
How can we monitor the outbox to detect delivery issues?
Are there any specific considerations when using Azure Service Bus instead of RabbitMQ?
How does MassTransit handle outbox cleanup to prevent the tables from growing indefinitely?

Resources

Action Items

[ ] Create a proof-of-concept implementation of the Bus Outbox in our Order API
[ ] Benchmark performance differences between direct publishing and outbox publishing
[ ] Implement the Consumer Outbox in our Order Processing Service
[ ] Create monitoring for the outbox tables to detect delivery issues
[ ] Update our development guidelines to include the Outbox pattern

Related Skills

Entity Framework Core
Message-based architectures
Distributed systems design patterns
SQL Server (or other database systems)
MassTransit configuration and usage

Teaching Notes

The Outbox pattern is fundamentally about solving the dual-write problem in distributed systems
Emphasize that this pattern decouples database transactions from message broker availability
The key benefit is guaranteed message delivery even in case of system failures
Important distinction: Bus Outbox for API/web scenarios, Consumer Outbox for message handlers

Real World Example: E-commerce Order Processing System

In our e-commerce platform, we have these services:

Order Service: Manages customer orders
Inventory Service: Manages product inventory
Payment Service: Processes payments
Shipping Service: Manages shipping logistics
Notification Service: Sends notifications to customers

The Problem Scenario

When a customer places an order:

The Order Service saves the order in its database
It publishes an OrderPlaced event
Multiple services need to react:
- Inventory Service reserves stock
- Payment Service processes payment
- Notification Service emails the customer

Without the Outbox pattern, if the Order Service crashes after saving the order but before publishing the event:

The order exists in the database
No services know about it
No stock is reserved, no payment processed
The customer receives no confirmation

The Solution with MassTransit Outbox

Order Service Implementation (Bus Outbox)

// OrderService - handling a new order
public async Task<OrderResult> CreateOrder(OrderRequest request)
{
    var order = new Order
    {
        CustomerId = request.CustomerId,
        Items = request.Items.Select(i => new OrderItem 
        { 
            ProductId = i.ProductId, 
            Quantity = i.Quantity,
            Price = i.Price
        }).ToList(),
        TotalAmount = request.Items.Sum(i => i.Price * i.Quantity),
        Status = "Created",
        CreatedDate = DateTime.UtcNow
    };

    _orderDbContext.Orders.Add(order);

    // Publish the OrderPlaced event - this will be saved to the outbox
    await _publishEndpoint.Publish<OrderPlaced>(new 
    {
        OrderId = order.Id,
        CustomerId = order.CustomerId,
        Items = order.Items.Select(i => new { i.ProductId, i.Quantity }),
        TotalAmount = order.TotalAmount,
        CreatedDate = order.CreatedDate
    });

    // Save both the order and the outbox message in a single transaction
    await _orderDbContext.SaveChangesAsync();

    return new OrderResult 
    { 
        OrderId = order.Id,
        Status = order.Status
    };
}

Inventory Service Implementation (Consumer Outbox)

public class ReserveInventoryConsumer : IConsumer<OrderPlaced>
{
    private readonly InventoryDbContext _dbContext;
    private readonly IPublishEndpoint _publishEndpoint;

    public ReserveInventoryConsumer(
        InventoryDbContext dbContext,
        IPublishEndpoint publishEndpoint)
    {
        _dbContext = dbContext;
        _publishEndpoint = publishEndpoint;
    }

    public async Task Consume(ConsumeContext<OrderPlaced> context)
    {
        var message = context.Message;
        var allItemsAvailable = true;
        var unavailableItems = new List<Guid>();

        // Process each order item
        foreach (var item in message.Items)
        {
            var inventory = await _dbContext.Inventory
                .FirstOrDefaultAsync(i => i.ProductId == item.ProductId);

            if (inventory == null || inventory.AvailableQuantity < item.Quantity)
            {
                allItemsAvailable = false;
                unavailableItems.Add(item.ProductId);
                continue;
            }

            // Reserve the inventory
            inventory.AvailableQuantity -= item.Quantity;
            inventory.ReservedQuantity += item.Quantity;

            // Create reservation record
            _dbContext.InventoryReservations.Add(new InventoryReservation
            {
                OrderId = message.OrderId,
                ProductId = item.ProductId,
                Quantity = item.Quantity,
                ReservedDate = DateTime.UtcNow,
                ExpirationDate = DateTime.UtcNow.AddHours(1) // Expire in 1 hour if not confirmed
            });
        }

        await _dbContext.SaveChangesAsync();

        // Publish results - these will be saved to the outbox
        if (allItemsAvailable)
        {
            await _publishEndpoint.Publish<InventoryReserved>(new
            {
                OrderId = message.OrderId,
                ReservationId = Guid.NewGuid(),
                ReservedDate = DateTime.UtcNow,
                ExpirationDate = DateTime.UtcNow.AddHours(1)
            });
        }
        else
        {
            await _publishEndpoint.Publish<InventoryShortage>(new
            {
                OrderId = message.OrderId,
                UnavailableItems = unavailableItems,
                ProcessedDate = DateTime.UtcNow
            });
        }

        // No need for SaveChangesAsync here
        // The Consumer Outbox will handle saving and delivering the messages
    }
}

Benefits in This Real-World Scenario

Reliability: If the Order Service crashes after saving the order, the Outbox delivery service will still publish the event when it recovers.
Consistency: The Inventory Service will either reserve all items or publish an InventoryShortage event, even if it crashes mid-processing.
Exactly-once Processing: If the Inventory Service receives the same OrderPlaced event multiple times (due to message broker redelivery), the Consumer Outbox inbox will ensure it's only processed once.
System Resilience: The system can handle temporary outages of any component without losing data or having inconsistent state.
Simplicity: Developers can write code that appears synchronous while getting the benefits of asynchronous, reliable messaging.

This approach ensures our e-commerce system maintains data consistency across services, can recover from failures gracefully, and provides a reliable experience for customers even when things go wrong behind the scenes.

Getting Started with HybridCache in .NET

Hootan Hemmati — Fri, 14 Mar 2025 17:01:15 +0000

The moment .NET developers have been waiting for is here: HybridCache, a game-changing caching solution, is now generally available! This isn’t just another caching library—it’s a powerful fusion of in-memory speed and distributed resilience, designed to tackle real-world scalability challenges head-on. Let’s dive into how HybridCache transforms applications, with a practical example that every developer can relate to.

The Problem: Scaling an Online Bookstore

Imagine running a high-traffic online bookstore. Your product pages are hit by thousands of requests per minute, and your database groans under the load. You’ve implemented basic in-memory caching, but during peak sales, your multi-server setup struggles with inconsistent data. When prices update or stock levels change, stale cache entries frustrate users. Worse, cache stampedes—when dozens of requests bombard the database simultaneously after a cache miss—cause sudden latency spikes.

The Solution: HybridCache’s Layered Approach

HybridCache elegantly solves these problems by combining two caching layers:

In-Memory Cache (blazing-fast access for frequent data).
Distributed Cache (e.g., Redis, SQL Server) for cross-instance consistency.

Here’s how it works in action for our bookstore:

Scenario 1: Loading Product Details

When a user requests "The .NET Encyclopedia," HybridCache first checks the local in-memory cache. If the book isn’t there, it queries the distributed cache. If still not found, it safely fetches the data from the database, caches it in both layers, and returns it. Subsequent requests from any server instance get consistent, fast results.

// Register HybridCache  
services.AddHybridCache(options =>  
{  
    options.DistributedCacheEntryOptions = new()  
    {  
        AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(30)  
    };  
});  

// In your ProductService  
public async Task<Product> GetProductAsync(string productId)  
{  
    return await _hybridCache.GetOrCreateAsync(  
        $"product-{productId}",  
        async () => await _db.Products.FindAsync(productId),  
        TimeSpan.FromMinutes(10) // In-memory expiration  
    );  
}

Scenario 2: Preventing Cache Stampedes

During a flash sale, 1,000 requests hit a cache miss for "C# for Speed Demons." Instead of overwhelming the database, HybridCache ensures only one call fetches the data. The other 999 requests wait patiently for the result, avoiding downtime or crashes.

Scenario 3: Instant Cache Invalidation

When an admin updates the price of "ASP.NET Core Mastery," HybridCache removes the stale entry from both caching layers. The next request repopulates the cache with fresh data, ensuring accuracy without manual intervention.

public async Task UpdateProductAsync(Product updatedProduct)  
{  
    await _db.SaveChangesAsync();  
    await _hybridCache.RemoveAsync($"product-{updatedProduct.Id}");  
}

Why Developers Are Excited

Speed Meets Consistency: Serve data at in-memory speeds while keeping all servers in sync.
Resilience Built-In: Automatic stampede protection and stale data avoidance.
Simplified Code: No more juggling separate caching libraries—HybridCache unifies the experience.
Cost Efficiency: Reduce database load by 80%+ during traffic spikes.

Real Impact for Real Applications

After integrating HybridCache, our hypothetical bookstore sees dramatic improvements:

Page load times drop from 500ms to 20ms during peak hours.
Database CPU usage plummets by 70%, saving cloud costs.
Zero stale pricing errors post-updates, boosting customer trust.

Ready to Transform Your App?

HybridCache isn’t just a tool—it’s a paradigm shift for .NET applications. Whether you’re running an e-commerce platform, a financial dashboard, or a social network, this library empowers you to scale gracefully while keeping code clean and resilient.

The future of caching is here, and it’s hybrid. Dive into the official Microsoft documentation and start modernizing your applications today. Your databases (and users) will thank thank you!

Comprehensive Guide to Implementing Audit Logging in .NET with EF Core Interceptors

Hootan Hemmati — Sun, 26 Jan 2025 18:10:05 +0000

Audit logging is a critical component of modern applications, providing transparency, security, and compliance. This guide explores a sophisticated audit logging solution using Entity Framework Core (EF Core) Interceptors, explaining each component in detail, providing real-world examples, and discussing best practices for implementation.

Introduction to Audit Logging
Core Components Overview
Deep Dive into the Audit Interceptor
Real-World Example: E-Commerce Product Updates
Advanced Configuration & Best Practices
Performance Considerations
Security Implications
Future Enhancements

1. Introduction to Audit Logging

Audit logging captures who changed what data and when, serving three primary purposes:

Regulatory Compliance
- GDPR, HIPAA, PCI-DSS requirements
- Legal evidence in disputes
Operational Integrity
- Debugging data anomalies
- Recovery from accidental changes
Business Intelligence
- User behavior analysis
- Change pattern recognition

Traditional approaches often require manual logging in every service method. Our EF Core Interceptor solution automates this process through database-level observation.

2. Core Components Overview

2.1 Audit Log Entity

public class AuditLog
{
    public long Id { get; set; }
    public string TableName { get; set; }        // Modified entity type
    public long RecordId { get; set; }           // Modified record ID
    public string Operation { get; set; }        // CREATE/UPDATE/DELETE
    public string OldValues { get; set; }        // JSON snapshot before changes
    public string NewValues { get; set; }        // JSON snapshot after changes
    public long ModifiedBy { get; set; }         // User ID from context
    public DateTimeOffset ModifiedAt { get; set; } // UTC timestamp
}

2.2 User Context Service

public interface IUserContext
{
    long? CurrentUserId { get; }
}

// Implementation fetching user from JWT
public class JwtUserContext : IUserContext
{
    private readonly IHttpContextAccessor _contextAccessor;

    public JwtUserContext(IHttpContextAccessor contextAccessor) 
        => _contextAccessor = contextAccessor;

    public long? CurrentUserId => 
        long.TryParse(
            _contextAccessor.HttpContext?.User.FindFirstValue(ClaimTypes.NameIdentifier), 
            out var userId
        ) ? userId : null;
}

2.3 Audit Interceptor Architecture

sequenceDiagram
    participant Client
    participant DbContext
    participant AuditInterceptor
    participant Database

    Client->>DbContext: SaveChangesAsync()
    DbContext->>AuditInterceptor: SavingChangesAsync()
    AuditInterceptor->>AuditInterceptor: Analyze ChangeTracker
    AuditInterceptor->>Database: Save AuditLogs
    AuditInterceptor->>DbContext: Continue original save
    DbContext->>Database: Save business entities
    Database-->>DbContext: Success
    DbContext-->>Client: Result

3. Deep Dive into the Audit Interceptor

3.1 Change Detection Mechanism

The interceptor hooks into EF Core's SaveChangesAsync pipeline:

public override async ValueTask<InterceptionResult<int>> SavingChangesAsync(
    DbContextEventData eventData, 
    InterceptionResult<int> result,
    CancellationToken cancellationToken = default)
{
    // Prevent recursive saving
    if (_isSaving) return await base.SavingChangesAsync(...);

    try
    {
        _isSaving = true;
        var audits = new List<AuditLog>();

        foreach (var entry in eventData.Context.ChangeTracker.Entries())
        {
            if (ShouldAudit(entry))
                audits.Add(CreateAuditEntry(entry));
        }

        await SaveAudits(eventData.Context, audits);
        return await base.SavingChangesAsync(...);
    }
    finally 
    {
        _isSaving = false;
    }
}

private bool ShouldAudit(EntityEntry entry) =>
    entry.Entity is not AuditLog && 
    entry.State is EntityState.Added or EntityState.Modified or EntityState.Deleted;

3.2 Change Processing Logic

Handles different entity states with precision:

Added Entities

if (entry.State == EntityState.Added)
{
    audit.NewValues = JsonSerializer.Serialize(entry.CurrentValues.ToObject());
}

Deleted Entities

if (entry.State == EntityState.Deleted)
{
    audit.OldValues = JsonSerializer.Serialize(entry.OriginalValues.ToObject());
}

Modified Entities

var changes = entry.Properties
    .Where(p => p.IsModified && !Equals(p.OriginalValue, p.CurrentValue))
    .ToDictionary(
        p => p.Metadata.Name,
        p => new { Old = p.OriginalValue, New = p.CurrentValue }
    );

audit.OldValues = changes.Any() 
    ? JsonSerializer.Serialize(changes.ToDictionary(k => k.Key, k => k.Value.Old)) 
    : null;

audit.NewValues = changes.Any()
    ? JsonSerializer.Serialize(changes.ToDictionary(k => k.Key, k => k.Value.New))
    : null;

4. Real-World Example: E-Commerce Product Updates

4.1 Scenario: Price & Stock Adjustment

// Original product state
var product = new Product 
{
    Id = 1,
    Name = "Wireless Headphones",
    Price = 199.99m,
    Stock = 50
};

// User updates
product.Price = 179.99m;
product.Stock = 45;

// Save changes
await _context.SaveChangesAsync();

4.2 Generated Audit Log

{
  "Id": 315,
  "TableName": "Product",
  "RecordId": 1,
  "Operation": "Modified",
  "OldValues": {
    "Price": 199.99,
    "Stock": 50
  },
  "NewValues": {
    "Price": 179.99,
    "Stock": 45
  },
  "ModifiedBy": 2345,
  "ModifiedAt": "2024-02-21T09:30:45Z"
}

4.3 Querying Audit History

Find all price changes for a product:

var priceHistory = await _context.AuditLogs
    .Where(a => 
        a.TableName == "Product" &&
        a.RecordId == productId &&
        a.Operation == "Modified" &&
        a.OldValues.Contains("Price"))
    .OrderByDescending(a => a.ModifiedAt)
    .Select(a => new 
    {
        OldPrice = JsonDocument.Parse(a.OldValues).RootElement.GetProperty("Price").GetDecimal(),
        NewPrice = JsonDocument.Parse(a.NewValues).RootElement.GetProperty("Price").GetDecimal(),
        ChangedBy = a.ModifiedBy,
        ChangedAt = a.ModifiedAt
    })
    .ToListAsync();

5. Advanced Configuration & Best Practices

5.1 Configuration Options

services.AddDbContext<AppDbContext>(options =>
{
    options.UseSqlServer(configuration.GetConnectionString("Default"))
        .AddInterceptors(new AuditInterceptor(
            userContext: new JwtUserContext(),
            options: new AuditOptions
            {
                IgnoreUnchanged = true,
                MaxValueLength = 2000,
                SensitiveFields = { "PasswordHash", "CreditCardNumber" }
            }));
});

5.2 Best Practices

Data Retention Policy

   // Auto-delete logs older than 2 years
   services.AddHostedService<AuditLogCleanupService>();

   public class AuditLogCleanupService : BackgroundService
   {
       protected override async Task ExecuteAsync(CancellationToken stoppingToken)
       {
           while (!stoppingToken.IsCancellationRequested)
           {
               await _context.AuditLogs
                   .Where(a => a.ModifiedAt < DateTimeOffset.UtcNow.AddYears(-2))
                   .ExecuteDeleteAsync();

               await Task.Delay(TimeSpan.FromDays(1), stoppingToken);
           }
       }
   }

Performance Optimization
- Use database indexing:

   CREATE NONCLUSTERED INDEX IX_AuditLogs_Search 
   ON AuditLogs (TableName, RecordId, ModifiedAt DESC)

Custom Serialization

   var options = new JsonSerializerOptions
   {
       PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
       Encoder = JavaScriptEncoder.UnsafeRelaxedJsonEscaping
   };

   JsonSerializer.Serialize(data, options);

6. Performance Considerations

6.1 Impact Analysis

Operation	Without Audit	With Audit	Overhead
Insert 1000	120ms	450ms	275%
Update 1000	150ms	520ms	247%
Delete 1000	110ms	430ms	291%

6.2 Mitigation Strategies

Batching

Process audits in batches of 100 records
Asynchronous Logging

Use background queues for non-critical audits
Selective Auditing

Attribute-based opt-out:

   [Audit(Ignore = true)]
   public class TemporaryData
   {
       // ...
   }

7. Security Implications

7.1 Sensitive Data Handling

public class AuditInterceptor : SaveChangesInterceptor
{
    private readonly List<string> _sensitiveFields;

    public AuditInterceptor(/* ... */, List<string> sensitiveFields)
        => _sensitiveFields = sensitiveFields;

    private string SanitizeValues(IDictionary<string, object> values)
        => values.ToDictionary(
            kvp => kvp.Key,
            kvp => _sensitiveFields.Contains(kvp.Key) ? "**REDACTED**" : kvp.Value
        );
}

7.2 Access Control

Implement row-level security:

CREATE SECURITY POLICY AuditLogAccessPolicy
ADD FILTER PREDICATE dbo.fn_UserCanAccessAuditLog(@UserId, TableName, RecordId)
ON dbo.AuditLogs
WITH (STATE = ON);

8. Future Enhancements

8.1 Planned Features

Change Visualization

   public class AuditDiff
   {
       public static string GetHtmlDiff(string oldJson, string newJson)
       {
           // Generates side-by-side HTML comparison
       }
   }

Real-Time Notifications

   services.AddSignalR();

   public class AuditHub : Hub
   {
       public async Task SubscribeToAudits(string entityType, long entityId)
           => await Groups.AddToGroupAsync(Context.ConnectionId, $"{entityType}-{entityId}");
   }

Machine Learning Anomaly Detection

   public class AuditAnalyzer
   {
       public bool IsSuspiciousChange(AuditLog audit)
           => _model.Predict(new AuditFeatures(audit)) > 0.95;
   }

Conclusion

This EF Core audit logging solution provides:

Comprehensive Change Tracking

Minimal Code Impact

Enterprise-Grade Security

Scalable Architecture

By implementing this pattern, you establish a robust foundation for data governance while maintaining development agility. The system adapts to various use cases through:

Customizable serialization
Flexible user context integration
Performance-optimized logging

Why Span and Ref Structs Can't Directly Participate in Asynchronous Operations

Hootan Hemmati — Tue, 26 Nov 2024 21:20:52 +0000

Why Span and Ref Structs Can't Directly Participate in Asynchronous Operations
The core limitation stems from the fundamental nature of asynchronous operations and the lifetime management of Span and ref structs.

Stack-Based Nature of Span and Ref Structs
- Stack-Bound Lifetime: Span and ref structs are designed to be stack-allocated, meaning their lifetime is tied to the current function's execution context.
- Asynchronous Operation Lifespan: Asynchronous operations, however, can span multiple function calls and potentially multiple thread contexts. This mismatch in lifetimes can lead to undefined behavior if a Span or ref struct is passed to an asynchronous operation and then used after the original function returns.
Lack of Heap Allocation and Boxing
- No Heap Storage: Span and ref structs are designed to avoid heap allocations to minimize overhead. This prevents them from being easily stored in heap-based data structures, which are often necessary for asynchronous operations.
- No Boxing: Boxing, the process of converting a value type to a reference type, is not supported for Span and ref structs. This further limits their ability to be passed around in asynchronous contexts.

Workarounds and Alternatives
While Span and ref structs cannot be directly used in asynchronous operations, several strategies can be employed to work around this limitation:

Memory:
- A heap-allocated equivalent of Span that can be used in asynchronous operations.
- It provides methods to obtain Span instances when needed.
Passing Pointers:
- In certain scenarios, you can pass pointers to memory blocks to asynchronous operations. However, this requires careful memory management and can be less safe than using Memory.
Asynchronous Streams:
- For streaming data asynchronously, consider using asynchronous streams. These can be more efficient and easier to work with than traditional asynchronous operations.

Conclusion
While the limitations of Span and ref structs in asynchronous operations might seem restrictive, understanding the underlying reasons helps in choosing the appropriate approach for specific scenarios. By leveraging Memory and other techniques, you can still benefit from the performance advantages of Span and ref structs in asynchronous programming.

The Double-Edged Sword of IEnumerable and yield return in C#

Hootan Hemmati — Mon, 21 Oct 2024 20:34:18 +0000

IEnumerable and yield return are powerful features in C# that enable developers to create lazy sequences and write more efficient and readable code. However, like a double-edged sword, they can cause significant performance issues and unexpected behavior if not used correctly. In this post, we'll delve into how these features work, explore common pitfalls with real-world examples—including a database scenario—and provide best practices to help you use them effectively.

Understanding `IEnumerable` and `yield return`

Before diving into the pitfalls, it's essential to understand the mechanics of IEnumerable and yield return.

IEnumerable<T>: An interface that allows iteration over a collection of a specified type. It supports simple iteration over a generic collection.
yield return: A keyword that simplifies the implementation of iterator blocks. It allows a method to return each element one at a time, without creating an intermediate collection.

These features enable lazy evaluation, meaning the values are computed and returned only when required, potentially improving performance and reducing memory usage.

The Double-Edged Sword: Potential Pitfalls

While IEnumerable and yield return offer benefits, improper use can lead to:

Repeated expensive computations
Resource management issues
Unexpected side effects due to deferred execution

Let's explore these pitfalls with real-world examples.

Example 1: Repeated Expensive Computations

Problem

Suppose you have a method that generates a sequence with yield return, involving heavy computations:

public IEnumerable<int> GetExpensiveSequence()
{
    for (int i = 0; i < 1000; i++)
    {
        // Simulate an expensive operation
        Thread.Sleep(10);
        yield return i;
    }
}

When you use this sequence:

var sequence = GetExpensiveSequence();

var count = sequence.Count();
var sum = sequence.Sum();

Each enumeration of sequence triggers the entire computation again. In this case, Thread.Sleep(10) simulates a costly operation, leading to significant performance degradation because the computation runs multiple times.

Solution

To avoid repeated computations, materialize the sequence into a collection like List<T>:

var sequence = GetExpensiveSequence().ToList();

var count = sequence.Count;
var sum = sequence.Sum();

By calling ToList(), you execute the sequence once, store the results in memory, and reuse them without recomputing.

Example 2: Resource Management and Deferred Execution

Problem

Consider an IEnumerable that reads lines from a file:

public IEnumerable<string> ReadLines(string filePath)
{
    using (var reader = new StreamReader(filePath))
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            yield return line;
        }
    }
}

When you enumerate ReadLines, you might encounter an ObjectDisposedException. The StreamReader is disposed when the using block exits, but enumeration happens later due to deferred execution, leaving the reader unavailable.

Solution

Ensure the resource remains available during enumeration:

public IEnumerable<string> ReadLines(string filePath)
{
    var reader = new StreamReader(filePath);
    try
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            yield return line;
        }
    }
    finally
    {
        reader.Dispose();
    }
}

Alternatively, use built-in methods that handle resource management correctly, such as File.ReadLines(filePath).

Example 3: Unintended Multiple Database Queries

Problem

When using an ORM like Entity Framework, deferred execution can cause multiple database queries:

public IEnumerable<Customer> GetActiveCustomers()
{
    using (var context = new MyDbContext())
    {
        foreach (var customer in context.Customers.Where(c => c.IsActive))
        {
            yield return customer;
        }
    }
}

If you perform operations that enumerate GetActiveCustomers() multiple times, you execute multiple database queries. Additionally, since the DbContext is disposed after the method exits, you might encounter an ObjectDisposedException when you try to enumerate the results.

Solution

Materialize the results before exiting the using block:

public List<Customer> GetActiveCustomers()
{
    using (var context = new MyDbContext())
    {
        return context.Customers
                      .Where(c => c.IsActive)
                      .ToList();
    }
}

By calling ToList(), you execute the query within the scope of the DbContext, fetch the data once, and avoid multiple queries and disposal issues.

Example 4: Changes in External State Affect Enumeration

Problem

An IEnumerable that depends on an external collection can yield inconsistent results if the collection changes:

public IEnumerable<int> GetNumbers(List<int> numbers)
{
    foreach (var number in numbers)
    {
        yield return number;
    }
}

If the numbers list is modified after creating the sequence:

var numbers = new List<int> { 1, 2, 3 };
var sequence = GetNumbers(numbers);

// Modify the list
numbers.Add(4);

// Enumerate the sequence
foreach (var num in sequence)
{
    Console.WriteLine(num);
}

Output:

The addition of 4 affects the sequence, which might not be the intended behavior.

Solution

Capture the state at the time of sequence creation by iterating over a copy:

public IEnumerable<int> GetNumbers(List<int> numbers)
{
    foreach (var number in numbers.ToList())
    {
        yield return number;
    }
}

This ensures the sequence reflects the list's state at the time of creation.

Best Practices

To avoid pitfalls when using IEnumerable and yield return:

Understand Deferred Execution: Be aware that the sequence isn't executed until it's enumerated.
Avoid Multiple Enumerations of Expensive Operations: Materialize sequences that involve heavy computations using ToList() or ToArray().
Manage Resources Properly: Keep resources like files or database connections open during enumeration, or materialize the data before disposing of the resource.
Be Cautious with External State: If the underlying data might change, consider creating a snapshot.
Profile and Test: Always test your code to understand its performance characteristics and behavior.

Conclusion

IEnumerable and yield return can enhance your C# applications by enabling lazy evaluation and simplifying code. However, they require careful use to prevent performance issues and unintended side effects. By understanding how they work and following best practices, you can leverage these features effectively without compromising your application's performance and reliability.

Feel free to share your experiences or ask questions in the comments below!

References:

Thank you for reading! If you found this post helpful, consider following me for more insights on C# and .NET programming.

Elevating Dependency Injection in .NET with Scrutor and Autofac

Hootan Hemmati — Sat, 12 Oct 2024 15:56:18 +0000

As .NET developers, we're all familiar with the challenges of managing dependency injection (DI) in large projects. When the number of services and repositories grows, manually registering each one can become a time-consuming and tedious task. Fortunately, there are solutions that make this process simple and elegant: Scrutor and Autofac!

In my recent project, I needed to inject numerous services and repositories located across different class libraries effortlessly. By leveraging Scrutor, I managed to handle all these dependencies with just a few lines of code.

Let's dive into the code and explain each method:

services.Scan(current => current
    .FromAssemblies(typeof(Services.Service1).GetTypeInfo().Assembly)
    .AddClasses(theClass => theClass.InExactNamespaceOf<Services.Service1>())
    // For Service4 and Service5
    .AsSelf()
    // For Service1, Service2, Service3
    .AsImplementedInterfaces()
    .WithSingletonLifetime()

    .FromAssemblies(typeof(Repositories.Repository1).GetTypeInfo().Assembly)
    .AddClasses(theClass => theClass.InExactNamespaceOf<Repositories.Repository1>())
    // For Repository4 and Repository5
    .AsSelf()
    // For Repository1, Repository2, Repository3
    .AsImplementedInterfaces()
    .WithTransientLifetime()
);

Explanation of the methods and their purpose:

services.Scan(...): This method initiates the scanning and automatic registration of dependencies. It allows us to specify the assemblies and classes we want to scan.
FromAssemblies(...): Here, we tell Scrutor which assemblies to scan. By using typeof(Services.Service1).GetTypeInfo().Assembly, we're specifying the assembly that contains our services.
AddClasses(...): This method determines which classes should be registered. The InExactNamespaceOf<Services.Service1>() directive tells Scrutor to include only the classes in the exact namespace of Service1.
AsSelf(): Registers the classes as themselves. For example, if we have a class named Service4, we can inject it as Service4.
AsImplementedInterfaces(): Registers the classes as the interfaces they implement. This is useful when we want to use interfaces for dependency injection.
WithSingletonLifetime() and WithTransientLifetime(): These methods set the lifetime of the dependencies. Singleton means a single instance of the service exists throughout the application's lifetime, while Transient creates a new instance for each request.

Why Scrutor?

Simplified Dependency Injection: Eliminates the need to manually register each service and repository.
High Flexibility: Allows precise determination of classes, interfaces, and lifetimes.
Assembly Scanning Capability: You can scan classes from various assemblies and namespaces.

Introducing Autofac and Comparing it with Scrutor

But Scrutor isn't our only option. Autofac is another powerful library for managing dependency injection in .NET, offering advanced features.

What is Autofac?

Autofac is an Inversion of Control (IoC) container that provides developers with flexible and powerful ways to manage their dependencies. With Autofac, we can have greater control over how dependencies are created and injected.

Key Features of Autofac:

Modularity: Ability to partition dependency registrations into separate modules for better organization.
Precise Lifetime Control: Advanced options for setting dependency lifetimes, such as InstancePerDependency, SingleInstance, InstancePerLifetimeScope, etc.
Support for AOP (Aspect-Oriented Programming): Allows the use of interceptors to add extra behaviors to services.
Integration with Various Frameworks: Supports ASP.NET Core, WCF, Web API, and more.

How to Use Autofac:

Install Autofac: First, install the Autofac NuGet packages and its ASP.NET Core integration.
Setup in Startup.cs:

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    // Register default services
    services.AddControllers();

    // Create a ContainerBuilder
    var builder = new ContainerBuilder();

    // Transfer default registrations to Autofac
    builder.Populate(services);

    // Register dependencies
    builder.RegisterType<MyService>().As<IMyService>().InstancePerLifetimeScope();

    // Build the container
    var container = builder.Build();

    // Return the IServiceProvider from Autofac
    return new AutofacServiceProvider(container);
}

Using Modules:

You can organize your dependencies into modules:

public class ServiceModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterType<Service1>().As<IService1>();
        builder.RegisterType<Service2>().As<IService2>();
    }
}

Then, register the module in ConfigureServices:

builder.RegisterModule(new ServiceModule());

Comparing Scrutor and Autofac:

Feature	Scrutor	Autofac
Simplicity	Simple and lightweight, ideal for auto-registering dependencies	Powerful but with added complexity
Lifetime Control	Basic control with `With...Lifetime()` methods	Advanced control with various lifetime scopes
Modularity	Not available	Supports modules for better organization
AOP Support	Limited support	Strong support for interceptors and AOP
Integration	Uses default DI container of ASP.NET Core	Replaces default container with Autofac

Which One to Choose?

Scrutor is ideal for projects that want to simplify dependency registration using the default DI container of ASP.NET Core without adding extra complexity.
Autofac is suitable for larger, more complex projects that require finer control and advanced features in dependency management.

Conclusion

Both libraries are powerful tools for managing dependency injection in .NET. Your choice between them depends on your project's needs and the level of control you require. If you're looking for simplicity and speed, Scrutor is an excellent option. But if you need more advanced features, Autofac can meet your demands.

Ultimately, our main goal is to improve code structure, enhance maintainability, and accelerate development. So choose the right tool carefully and enjoy its benefits.

Moving Git Stashes Between Devices: A Step-by-Step Guide

Hootan Hemmati — Sun, 14 Jul 2024 20:27:18 +0000

Git stashes are a powerful feature that allows developers to temporarily store uncommitted changes. But what if you need to move these stashes to another device? In this post, we'll walk through the process of transferring your Git stashes, ensuring you don't lose any valuable work-in-progress.

Prerequisites

Before we begin, let's set up Git to include untracked files in our stashes:

git config stash.showIncludeUntracked true

This configuration ensures that when we create a stash, it includes all changes, even those in untracked files.

Step 1: Create a Stash

On your current device, stash your changes:

git stash push -u

The -u flag includes untracked files in the stash.

Step 2: Create a Patch File

Now, let's create a patch file from the stash:

git stash show "stash@{0}" -p > changes.patch

This command creates a file named changes.patch containing all the changes in your most recent stash.

Step 3: Transfer the Patch File

Transfer the changes.patch file to your other device. You can use various methods like email, cloud storage, or a USB drive.

Step 4: Apply the Patch on the New Device

On your new device, navigate to your Git repository and apply the patch:

git apply changes.patch

This command applies the changes from the patch file to your working directory.

Example Workflow

Let's walk through an example to illustrate this process:

On Device A, you're working on a feature but need to switch tasks:

   # Make some changes to files
   echo "New feature code" >> feature.txt

   # Stash the changes
   git stash push -u

   # Create a patch file
   git stash show "stash@{0}" -p > my_feature_changes.patch

Transfer my_feature_changes.patch to Device B.
On Device B:

   # Navigate to your repository
   cd /path/to/your/repo

   # Apply the patch
   git apply my_feature_changes.patch

Now, all the changes you stashed on Device A are available in your working directory on Device B.

Additional Tips

You can create multiple patch files for different stashes by changing the stash reference (e.g., stash@{1}, stash@{2}).
After applying the patch, you might want to commit the changes or create a new stash on the new device.
Always ensure you're in the correct repository and branch before applying patches.

By following these steps, you can easily move your Git stashes between devices, maintaining your workflow continuity no matter where you're working.

Dev Tunnels in Visual Studio: Your Secret Weapon for Effortless Web API Debugging

Hootan Hemmati — Thu, 08 Feb 2024 21:10:34 +0000

Developing and testing web APIs can be a frustrating experience, especially when restricted by localhost access. Firewalls, network configurations, and limited access often create roadblocks, hindering collaboration and efficient debugging. But fear not, weary developer! Visual Studio introduces dev tunnels, a powerful tool that shatters these barriers and unlocks a world of streamlined API development.

Imagine this: You're working on a cutting-edge web API. You need feedback from colleagues, want to test it within Power Automate, and require seamless debugging from multiple devices. Traditionally, this scenario would involve complex network configurations, VPNs, and potential security concerns. However, dev tunnels eliminate these challenges entirely.

So, what exactly are dev tunnels?

Think of them as secure, temporary bridges that connect your locally running web API to the vast internet. Dev tunnels create a publicly accessible URL, granting anyone with an internet connection the ability to interact with your API. It's like magic, but powered by secure technology!

Why should you ditch the old methods and embrace dev tunnels?

Effortless Testing: Share the generated URL with anyone, be it colleagues, testers, or external services. No more fiddling with complicated setups - everyone can access your API with ease.
Debug Like a Pro: Test and debug your API directly within tools like Power Automate and Power Apps. This seamless integration removes the need for manual testing and streamlines your development workflow.
Security First: Dev tunnels leverage the robust security of Microsoft Azure, ensuring your API remains protected even when publicly accessible. You can rest assured knowing sensitive data is never compromised.
Dynamic URLs: Each tunnel generates a unique URL, offering granular control over access. Choose between persistent or temporary tunnels depending on your needs, ensuring security and flexibility.

Getting Started with Dev Tunnels is a Breeze:

Open your ASP.NET Core project in Visual Studio.
In the Debug dropdown menu, select Dev Tunnels > Create a Tunnel.
Configure your tunnel settings, including a name, duration, and authentication type (public or private).
Start debugging your API - the generated URL will be displayed, ready to be shared with the world!

Beyond the Basics:

Power Automate and Power Apps Integration: Dev tunnels become even more powerful when combined with these platforms. Test and debug custom connectors directly, saving you time and frustration.
Collaboration Made Easy: Share the tunnel URL with your team for efficient testing and feedback cycles. This collaborative approach accelerates development and ensures everyone is on the same page.
Advanced Features: Dev tunnels offer granular control through customizable options like port forwarding and access restrictions. Tailor the experience to your specific needs and security requirements.

Dev tunnels are more than just a cool feature; they're a game-changer for web API development. By streamlining testing, collaboration, and debugging, they empower you to create high-quality APIs faster and more efficiently. Ditch the old methods and embrace the secure, accessible world of dev tunnels - your code and your sanity will thank you!

5 Essential EF Core Performance Tips

Hootan Hemmati — Fri, 26 Jan 2024 22:14:41 +0000

Optimizing EF Core for better performance is crucial for developing responsive applications. Here are five key strategies, as highlighted by Milan Jovanović, to enhance your EF Core queries, complete with straightforward code examples.

1. No Tracking Queries

Why: EF Core's default behavior tracks changes to entities, which is unnecessary for read-only operations and can slow down performance.

Solution: Use .AsNoTracking() for queries where you don't need to track changes, reducing memory usage and improving query speed.

Code Example:

var users = context.Users.AsNoTracking().ToList();

2. Selecting the Right Columns

Why: Retrieving all columns when you only need a few can lead to inefficient data transfer.

Solution: Use .Select() to specify exactly which columns to retrieve, minimizing data transfer and speeding up the query.

Code Example:

var userNames = context.Users.Select(u => new { u.Id, u.Name }).ToList();

3. Leveraging Relationships Effectively

Why: Loading related data inefficiently can significantly impact performance.

Solution: Use .Include() carefully. Consider lazy loading or explicit loading to fetch related data as needed, rather than all at once.

Code Example:

var usersWithOrders = context.Users.Include(u => u.Orders).ToList();

4. Using Split Queries

Why: Complex queries involving multiple joins can be more efficiently executed as separate queries.

Solution: For EF Core 5.0 and later, use .AsSplitQuery() for complex joins to break them into multiple queries, potentially reducing execution time.

Code Example:

var orders = context.Orders.Include(o => o.Items).AsSplitQuery().ToList();

5. Implementing Pagination

Why: Loading large datasets in one go can overwhelm your application and lead to long load times.

Solution: Implement pagination to load data in manageable chunks, improving user experience and reducing server load.

Code Example:

int pageSize = 10;
var page = context.Users.Skip((pageNumber - 1) * pageSize).Take(pageSize).ToList();

Conclusion

By applying these EF Core performance tips, you can make your applications more efficient and responsive. Each strategy addresses a common performance pitfall, helping you to optimize data access patterns and improve overall application performance.

Navigate the Unexpected: Using Copilot in Edge and DevTools

Hootan Hemmati — Fri, 12 Jan 2024 22:16:08 +0000

In the ever-evolving landscape of web development, encountering unexpected errors and warnings is inevitable. These roadblocks can often bring development to a screeching halt, leaving developers scrambling for solutions. Fortunately, Microsoft Edge has introduced a powerful tool called Copilot that can help developers navigate these challenges with ease.

What is Copilot?

Copilot is a built-in AI assistant within Edge DevTools that leverages the power of machine learning to understand and explain errors and warnings encountered during development. It acts as a virtual companion, providing real-time insights and suggestions to help developers quickly diagnose and resolve issues.

Unveiling the Mysteries of Errors and Warnings

One of Copilot's most valuable capabilities is its ability to demystify cryptic error messages and warnings. By simply hovering over an error or warning in the DevTools console, Copilot instantly surfaces contextual explanations, potential causes, and even suggested fixes. This eliminates the need for developers to spend hours scouring through documentation or online forums for answers.

Beyond Error Decoding: Understanding Code Snippets

Copilot's prowess extends beyond just deciphering error messages. It can also analyze and explain snippets of code, providing insights into their functionality and potential pitfalls. This is particularly helpful for understanding complex codebases or unfamiliar libraries. Imagine being able to instantly grasp the purpose and behavior of a piece of code simply by selecting it and letting Copilot do its magic.

Boosting Developer Productivity

The time saved by Copilot's explanations and suggestions translates to increased developer productivity. By resolving issues faster and avoiding rabbit holes of troubleshooting, developers can dedicate more time to core development tasks. This translates to faster development cycles, improved code quality, and ultimately, a more enjoyable development experience.

A Symbiotic Relationship with DevTools

Copilot's integration with DevTools is seamless and intuitive. Its functionalities are readily accessible within the familiar DevTools interface, making it easy for developers to leverage its power without disrupting their workflow. This tight integration ensures that Copilot is always within reach, ready to assist whenever needed.

The Future of Web Development with Copilot

As web development continues to evolve at breakneck speed, the need for intelligent and assistive tools like Copilot becomes even more critical. Copilot represents a significant leap forward in developer tooling, paving the way for a future where developers can work more efficiently and effectively. With its ability to explain the unexpected, Copilot is poised to become an indispensable companion for web developers of all levels.

From Angular to Blazor: Unleashing the C# Magic!

Hootan Hemmati — Thu, 09 Nov 2023 19:20:41 +0000

Embarking on the journey of migrating an Angular component to a Blazor component is an exhilarating adventure that promises not only a change in syntax but a transformative shift in the way you approach web development. As you step into the world of Blazor, powered by the robust C# language and the expansive .NET ecosystem, you're not just migrating code; you're unlocking a realm of possibilities that seamlessly blend client and server-side logic.

Imagine the thrill of translating your Angular masterpiece into a Blazor gem, where the familiar dances with the novel, and where the precision of C# orchestrates the symphony of your web application. This migration isn't merely a technical transition; it's an opportunity to leverage the full spectrum of .NET capabilities, from razor-sharp data binding to the elegance of C# event handling.

So, fasten your seatbelt and get ready to witness the fusion of Angular's dynamism with Blazor's C# prowess. In this exhilarating guide, we'll navigate through each step of the migration process, unveiling the magic that happens when you bring the best of both worlds together. Get ready for a coding adventure that will not only elevate your skill set but also inject a burst of excitement into your development journey. Let the migration begin!

Migrating from Angular to Blazor can be an exciting journey, and it's essential to understand the steps involved. Blazor is a web framework by Microsoft that allows developers to build interactive web applications using C# instead of JavaScript. Here's a step-by-step guide on how to migrate an Angular component to a Blazor component:

Step 1: Understand the Basics of Blazor

Before you start the migration process, it's crucial to have a basic understanding of Blazor. Blazor supports both client-side (WebAssembly) and server-side rendering. Make sure to choose the approach that best fits your project requirements.

Step 2: Install Blazor Project Template

If you haven't already, install the Blazor project template using the .NET CLI. Open a terminal and run the following command:

dotnet new -i Microsoft.AspNetCore.Components.Web.Templates::3.0.0-preview9.19465.2

Then, create a new Blazor project:

dotnet new blazor -n YourBlazorApp

Step 3: Create a Blazor Component

Create a new Blazor component to replace the Angular component. Blazor components have a similar structure to Razor views. You can use the .razor file extension. For example, create a file named MyBlazorComponent.razor.

Step 4: Port HTML and CSS

Copy the HTML and CSS code from your Angular component to the new Blazor component. Since Blazor uses Razor syntax for components, you might need to make some adjustments to the HTML, especially if it includes Angular-specific directives or bindings.

Step 5: Update Data Binding

Blazor uses C# for data binding instead of Angular's two-way data binding. Update the data binding logic in your Blazor component using C# syntax. For example, if you had Angular code like:

<input [(ngModel)]="name" />

In Blazor, you would bind it like:

<input @bind="name" />

Step 6: Replace Angular Services with .NET Services

If your Angular component relies on services, you'll need to replace them with .NET services in Blazor. Create corresponding service classes in your Blazor project and inject them into the component using dependency injection.

Step 7: Update Event Handling

Update event handling in your Blazor component using C# event handlers instead of Angular event bindings. For example, replace (click)="handleClick()" in Angular with @onclick="HandleClick" in Blazor.

Step 8: Migrate Routing

If your Angular component is part of a larger application with routing, you'll need to migrate the routing logic to Blazor. Blazor uses @page directive for routing.

Step 9: Test and Debug

Thoroughly test your migrated Blazor component. Use the browser's developer tools and Visual Studio debugging tools to identify and fix any issues that may arise during the migration process.

Step 10: Gradual Migration

Consider a gradual migration approach if your application is extensive. You can migrate one component at a time, testing and validating each step to ensure a smooth transition.

Let's Begin Our Migration

Let's add a simple example to illustrate the migration process. Suppose you have an Angular component that displays a list of items with a search functionality. Here's how you might migrate it to a Blazor component:

Angular Component (Original)

<!-- app.component.html -->
<div>
  <input [(ngModel)]="searchTerm" placeholder="Search items" />
</div>

<ul>
  <li *ngFor="let item of filteredItems">{{ item.name }}</li>
</ul>

// app.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  items = [
    { name: 'Item 1' },
    { name: 'Item 2' },
    { name: 'Item 3' },
    // ... more items
  ];

  searchTerm: string = '';

  get filteredItems() {
    return this.items.filter(item => item.name.toLowerCase().includes(this.searchTerm.toLowerCase()));
  }
}

Blazor Component (Migrated)

<!-- MyBlazorComponent.razor -->
<div>
  <input @bind="searchTerm" placeholder="Search items" />
</div>

<ul>
  @foreach (var item in filteredItems)
  {
    <li>@item.Name</li>
  }
</ul>

@code {
  List<Item> items = new List<Item>
  {
    new Item { Name = "Item 1" },
    new Item { Name = "Item 2" },
    new Item { Name = "Item 3" },
    // ... more items
  };

  string searchTerm = "";

  List<Item> filteredItems => items
    .Where(item => item.Name.ToLower().Contains(searchTerm.ToLower()))
    .ToList();

  public class Item
  {
    public string Name { get; set; }
  }
}

In this example:

The HTML structure remains similar, but the syntax and data binding differ.
The Angular two-way binding [(ngModel)] is replaced with @bind in Blazor.
Angular's *ngFor directive is replaced with @foreach in Blazor.
The event handling and data binding in the code block (@code) use C# syntax in the Blazor component.
Angular's TypeScript class is replaced with a C# class in Blazor.

This is a simplified example, but it captures the essence of migrating a basic component from Angular to Blazor. Keep in mind that more complex applications may require additional considerations and adjustments.

Conclusion

Migrating from Angular to Blazor involves understanding the differences in syntax, data binding, and architecture. By following these steps, you can successfully migrate your Angular component to a Blazor component, taking advantage of the benefits that Blazor and the .NET ecosystem offers.

The Art of C# Pattern Matching

Hootan Hemmati — Sat, 22 Jul 2023 21:21:08 +0000

Pattern matching in C# is a powerful feature introduced in C# 7.0 and improved upon in later versions. It enables developers to perform concise and expressive checks on data structures, making it easier to work with complex types and perform conditional operations. Pattern matching is particularly helpful in the following situations:

Switch Statements

Pattern matching enhances switch statements, allowing developers to match cases based on complex patterns rather than just simple constant values. It enables the use of various patterns like type patterns, property patterns, tuple patterns, and more, making switch statements more versatile and readable.

Example:

public string GetVehicleType(object vehicle)
{
    switch (vehicle)
    {
        case Car _:
            return "Car";
        case Bike _:
            return "Bike";
        case Truck _:
            return "Truck";
        default:
            return "Unknown";
    }
}

Type Patterns

Pattern matching can be used to check the type of an object and perform actions based on the type. It simplifies type checking and casting, eliminating the need for explicit type checks and conversions.

Example:

public void ProcessShape(Shape shape)
{
    if (shape is Circle circle)
    {
        // Do something with circle
    }
    else if (shape is Rectangle rectangle)
    {
        // Do something with rectangle
    }
    // More type patterns can be added here
}

Property Patterns

Property patterns allow pattern matching based on the properties of an object. It is particularly useful when working with complex data structures or domain models.

Example:

public string GetWeatherMessage(WeatherInfo info)
{
    return info switch
    {
        { Temperature: < 0 } => "It's freezing outside!",
        { Temperature: >= 30, IsSunny: true } => "It's a hot and sunny day!",
        { IsRainy: true } => "Don't forget your umbrella!",
        _ => "Weather is moderate."
    };
}

Tuple Patterns

Pattern matching with tuples simplifies working with tuples and deconstructing their elements in a more readable manner.

Example:

public string GetQuadrantName((int x, int y) point)
{
    return point switch
    {
        (0, 0) => "Origin",
        (var x, var y) when x > 0 && y > 0 => "Quadrant I",
        (var x, var y) when x < 0 && y > 0 => "Quadrant II",
        // More tuple patterns can be added here
        _ => "Other Quadrant"
    };
}

Deconstruction

Pattern matching can be used in conjunction with deconstruction to extract values from complex objects easily.

Example:

var (firstName, lastName) = GetFullName("John Doe");

Null Check and Nullable Patterns

Pattern matching can also simplify null checks and handle nullable types more effectively.

Example:

public string GetCountryName(Country? country)
{
    return country switch
    {
        { Name: string name } => name,
        null => "Unknown Country"
    };
}

Summary:
Pattern matching in C# simplifies complex conditional checks, type handling, and deconstruction, making the code more expressive, concise, and readable. By enabling the use of various patterns, developers can write more robust code with fewer null reference exceptions and type-related issues. Pattern matching is a valuable addition to C#, allowing developers to work with complex data structures and types more efficiently.

Forem: Hootan Hemmati

Learning - MassTransit Transactional Outbox Pattern

Context

Key Concepts

Detailed Notes

Concept 1: The Problem - Atomic Operations Between Database and Message Broker

Concept 2: The Transactional Outbox Pattern Solution

Concept 3: MassTransit's Implementation - Bus Outbox

Concept 4: MassTransit's Implementation - Consumer Outbox

Code Examples

Example 1: Configuring the Bus Outbox with SQL Server and Entity Framework Core

Example 2: Using the Bus Outbox in a Controller/Service

Example 3: Configuring the Consumer Outbox

Example 4: Using the Consumer Outbox in a Consumer

Example 5: Creating the Entity Framework DbContext for the Outbox

Application to Current Work

Questions for Further Exploration

Resources

Action Items

Related Skills

Teaching Notes

Real World Example: E-commerce Order Processing System

The Problem Scenario

The Solution with MassTransit Outbox

Order Service Implementation (Bus Outbox)

Inventory Service Implementation (Consumer Outbox)

Benefits in This Real-World Scenario

Getting Started with HybridCache in .NET

The Problem: Scaling an Online Bookstore

The Solution: HybridCache’s Layered Approach

Scenario 1: Loading Product Details

Scenario 2: Preventing Cache Stampedes

Scenario 3: Instant Cache Invalidation

Why Developers Are Excited

Real Impact for Real Applications

Ready to Transform Your App?

Comprehensive Guide to Implementing Audit Logging in .NET with EF Core Interceptors

Table of Contents

1. Introduction to Audit Logging

2. Core Components Overview

2.1 Audit Log Entity

2.2 User Context Service

2.3 Audit Interceptor Architecture

3. Deep Dive into the Audit Interceptor

3.1 Change Detection Mechanism

3.2 Change Processing Logic

4. Real-World Example: E-Commerce Product Updates

4.1 Scenario: Price & Stock Adjustment

4.2 Generated Audit Log

4.3 Querying Audit History

5. Advanced Configuration & Best Practices

5.1 Configuration Options

5.2 Best Practices

6. Performance Considerations

6.1 Impact Analysis

6.2 Mitigation Strategies

7. Security Implications

7.1 Sensitive Data Handling

7.2 Access Control

8. Future Enhancements

8.1 Planned Features

Conclusion

Why Span and Ref Structs Can't Directly Participate in Asynchronous Operations

The Double-Edged Sword of IEnumerable and yield return in C#

Understanding IEnumerable and yield return

The Double-Edged Sword: Potential Pitfalls

Example 1: Repeated Expensive Computations

Problem

Solution

Example 2: Resource Management and Deferred Execution

Problem

Solution

Example 3: Unintended Multiple Database Queries

Problem

Solution

Example 4: Changes in External State Affect Enumeration

Problem

Solution

Best Practices

Conclusion

Understanding `IEnumerable` and `yield return`