DEV Community: syauqi fuadi

From C# to TypeScript: Your Cozy Guide to Microsoft’s Dynamic Duo

syauqi fuadi — Mon, 21 Apr 2025 21:49:08 +0000

Hey there, fellow C# dev! 🎮 If you’ve ever wondered, “How different can TypeScript be? It’s from Microsoft too!”—you’re in for a treat. Let’s unpack how your C# skills will give you a head start, and where TypeScript will nudge you to think differently. Buckle up for a fun ride!

Why TypeScript Feels Like Home

1. “Wait, I’ve Seen This Before!” – Static Typing

If you love the safety of int age = 30; in C#, TypeScript’s let age: number = 30; will feel like slipping into your favorite coding hoodie. Both languages let you lock down types upfront, catching bugs early. No more “stringly typed” JavaScript surprises!

// TypeScript  
function greet(name: string): string {  
  return `Hello, ${name}!`;  
}  

// C#  
string Greet(string name) => $"Hello, {name}!";

2. OOP Soulmates: Classes & Interfaces

TypeScript’s classes and interfaces mirror C#’s elegance. Need a Person class with a contract? Easy-peasy:

interface IPerson {  
  name: string;  
  age: number;  
}  

class Person implements IPerson {  
  constructor(public name: string, public age: number) {}  
}

Swap interface for C#’s interface, and you’re golden! Even access modifiers (public, private) work the same way.

3. Generics: Your Code’s Reusable Blueprint

Love writing flexible code in C# with List<T>? TypeScript’s generics are practically twins:

function identity<T>(arg: T): T {  
  return arg;  
}  

// C#: T Identity<T>(T arg) => arg;

4. Async/Await: Same Superpower, New Playground

No need to relearn asynchronous patterns! The async/await you rely on in C# works identically in TypeScript:

async function fetchData() {  
  const data = await fetch('https://api.example.com');  
  return data.json();  
}

Where TypeScript Takes a Different Path

1. Runtime Reality Check

C# compiles to .NET IL and runs on the CLR. TypeScript? It’s a JavaScript superhero—transpiling to JS and running anywhere JS does (browsers, Node.js). Your types vanish at runtime, so no reflection magic here!

2. Structural Typing: Shape Over Name

In C#, a Dog class won’t match a Cat class, even if they have the same properties. TypeScript says, “If it walks and quacks like a duck, it’s a duck!”

interface Duck {  
  quack(): void;  
}  

function makeSound(duck: Duck) { /* ... */ }  

const fakeDuck = { quack: () => console.log("Moo?") };  
makeSound(fakeDuck); // ✅ Works in TypeScript!

C# devs: “Wait, that’s allowed?!” 😲

TypeScript: “Yes, and it’s glorious.”

3. The Wild `any` Card

TypeScript lets you opt out of strict typing with any (like dynamic in C#). Use it sparingly—it’s the “I’ll clean this up later” escape hatch.

4. Tooling: npm > NuGet

Swap NuGet for npm and get cozy with package.json. Your IDE buddy? VS Code (another Microsoft gem!) with killer TypeScript support.

Your Cheat Sheet for a Smooth Transition

Enable strict Mode

Add "strict": true in tsconfig.json to avoid JavaScript’s “gotchas” (like undefined surprises).
Play with the TypeScript Playground

Test snippets instantly at typescriptlang.org/play.
Embrace JavaScript’s Quirks

Learn JS fundamentals (e.g., this scoping, prototypal inheritance)—they’re TypeScript’s foundation.

Final Thought: Why You’ll Love TypeScript

Microsoft designed both languages to make developers’ lives easier. Your C# muscle memory—static types, OOP patterns, clean tooling—translates beautifully. TypeScript just adds a sprinkle of JavaScript flexibility.

So go ahead: build a web app, tweak a React component, or automate tasks with Node.js. Your C# skills aren’t just relevant—they’re your secret weapon. 🚀

Happy coding, and welcome to the TypeScript party! 🎉

Choosing a Front-End for .NET Development

syauqi fuadi — Sun, 13 Apr 2025 05:54:01 +0000

Here’s a practical guide to pairing .NET with front-end options, including code examples to help you decide:

1. Traditional HTML/JavaScript + Lightweight Libraries

Example 1: HTMX + .NET API

Goal: Fetch data from a .NET API and update the page without writing JavaScript.
Backend (C#) Return HTML instead of JSON using Razor views:

// WeatherController.cs  
[HttpGet("html")]  
public IActionResult GetWeatherHtml()  
{  
    var forecasts = new[] { "Sunny", "Cloudy", "Rainy" };  
    return PartialView("_WeatherPartial", forecasts);  
}

Create a Razor partial view (_WeatherPartial.cshtml):

@model string[]  
<ul class="weather-list">  
    @foreach (var forecast in Model)  
    {  
        <li>@forecast</li>  
    }  
</ul>

Frontend (HTML with HTMX)

<!-- Load HTMX -->  
<script src="https://unpkg.com/htmx.org"></script>  

<!-- Button triggers HTML response, replaces #weather-container -->  
<button  
  hx-get="/weather/html"  
  hx-target="#weather-container"  
  hx-indicator="#loading"  
>  
  Load Weather  
</button>  

<!-- Loading spinner (shown during request) -->  
<div id="loading" class="hidden">Loading...</div>  

<!-- Where the HTML response will be inserted -->  
<div id="weather-container"></div>  

<style>  
  .hidden { display: none; }  
  [hx-indicator="#loading"]:not([hx-disabled-elt]) + #loading {  
    display: block;  
  }  
</style>

Example 2: Alpine.js + Razor Pages

Goal: Create a reactive counter without complex setup.
Frontend (Razor Page):

  <!-- Counter.cshtml -->
  <div x-data="{ count: 0 }">
      <button @click="count++">+</button>
      <span x-text="count"></span>
      <button @click="count--">-</button>
  </div>
  <script src="https://unpkg.com/alpinejs" defer></script>

2. Modern Frameworks (React/Vue/Angular)

Example 1: React + .NET Web API

Goal: Build a dynamic list of items fetched from a .NET API.
React Component:

  // App.jsx
  import { useEffect, useState } from 'react';

  function App() {
      const [items, setItems] = useState([]);

      useEffect(() => {
          fetch('/api/items')  // Calls your .NET API
              .then(res => res.json())
              .then(data => setItems(data));
      }, []);

      return (
          <ul>
              {items.map(item => <li key={item.id}>{item.name}</li>)}
          </ul>
      );
  }

Setup: Use the dotnet new react template for a preconfigured React + .NET project.

Example 2: Vue + .NET

Goal: Display a form that submits data to a .NET API.
Vue Component:

  <!-- FormComponent.vue -->
  <template>
    <form @submit.prevent="submitForm">
      <input v-model="name" placeholder="Enter name" />
      <button type="submit">Save</button>
    </form>
  </template>

  <script>
  export default {
      data() {
          return { name: '' };
      },
      methods: {
          submitForm() {
              fetch('/api/users', {
                  method: 'POST',
                  headers: { 'Content-Type': 'application/json' },
                  body: JSON.stringify({ name: this.name })
              });
          }
      }
  };
  </script>

3. Blazor (C# on the Front-End)

Example: Blazor Component

Goal: Create an interactive list using C# instead of JavaScript.
Component:

  <!-- Weather.razor -->
  @page "/weather"
  @inject HttpClient Http

  <h3>Weather Forecast</h3>

  @if (forecasts == null) {
      <p>Loading...</p>
  } else {
      <ul>
          @foreach (var forecast in forecasts)
          {
              <li>@forecast</li>
          }
      </ul>
  }

  @code {
      private string[] forecasts;

      protected override async Task OnInitializedAsync()
      {
          // Calls your .NET API directly
          forecasts = await Http.GetFromJsonAsync<string[]>("api/weather");
      }
  }

When to Use What?

Scenario	Recommended Approach
Simple CRUD app	HTML + HTMX/Alpine.js + Razor
Team knows JavaScript well	React/Vue + .NET Web API
Avoid JavaScript entirely	Blazor
Legacy app maintenance	jQuery + MVC

Key Takeaways:

For quick results, stick to Razor Pages with Alpine.js or HTMX.
For complex UIs (e.g., dashboards), use React/Vue with a .NET Web API.
If you hate JavaScript, Blazor is your friend.

How to Become a Senior C# Developer: Action Steps

syauqi fuadi — Sun, 13 Apr 2025 04:50:02 +0000

Introduction:

Becoming a senior C# developer takes more than just time on the job. It requires growing your technical skills, developing professional qualities, and taking on bigger responsibilities. This guide offers practical steps to help you advance from a regular C# developer to a senior position.

Master C# Technical Skills:

Deepen your C# knowledge:

Study advanced C# features like LINQ, async/await, and delegates. Practice using these in your daily work, not just reading about them. For example, try refactoring an existing synchronous method to use async/await patterns in your current project.

Understand .NET ecosystem thoroughly:

Get comfortable with the latest .NET versions and their features. Build small practice projects using new capabilities. If you're still working with .NET Framework, create a side project using .NET 6/7/8 to experience the differences firsthand.

Learn design patterns:

Start applying common patterns like Repository, Factory, and Dependency Injection in your code. When you build a new feature, think about which pattern would make your code more maintainable and explain your choice to colleagues.

Master testing:

Write unit tests for all new code you produce. Set a goal to achieve good test coverage in your projects. Learn to use testing frameworks like NUnit or xUnit and practice test-driven development on a small feature.

Example:

// Instead of this:
public List<Customer> GetActiveCustomers()
{
    var customers = _database.GetAllCustomers();
    return customers.Where(c => c.IsActive).ToList();
}

// Write testable code like this:
public List<Customer> GetActiveCustomers(ICustomerRepository repository)
{
    return repository.GetAll().Where(c => c.IsActive).ToList();
}

Build System Architecture Knowledge:

Learn database design:

Practice creating efficient database schemas and writing optimized queries. Try to optimize an existing slow query in your project, measuring the performance before and after.

Study system architecture:

Understand how different parts of applications work together. Draw diagrams of systems you work on to visualize data flow and component interactions.

Explore microservices:

Build a small project using microservices architecture. Break down a monolithic application into smaller services that communicate with each other.

Practice with cloud services:

Set up a small application on Azure or AWS. Learn how to deploy, monitor, and scale applications in the cloud. Create a CI/CD pipeline for automatic deployment.

Develop Professional Skills:

Improve code reviews:

Give helpful, specific feedback during reviews. Instead of saying "this could be better," suggest how: "Consider using a factory pattern here to make this more maintainable."

Mentor others:

Offer to help junior developers with their tasks. Schedule regular sessions to answer their questions and review their progress on projects.

Communicate clearly:

Practice explaining technical concepts in simple terms. Try explaining your current project to someone outside your team and refine your explanation based on their questions.

Take ownership:

Volunteer to lead a small project or feature. Take responsibility for its success, from planning to deployment and maintenance.

Solving Complex Problems:

Break down big issues:

When facing a complex problem, divide it into smaller, manageable parts. Write out the steps needed to solve each part.

Research efficiently:

Develop a strategy for finding answers. Know which resources are reliable and relevant for C# development. Create a personal knowledge base of solutions you find.

Debug systematically:

Learn to use advanced debugging techniques in Visual Studio. Set conditional breakpoints, use watch windows effectively, and analyze memory usage to find performance issues.

Example approach:

// When debugging performance issues:
1. Use Stopwatch to measure execution time:
   var stopwatch = Stopwatch.StartNew();
   // Code to measure
   stopwatch.Stop();
   Console.WriteLine($"Execution time: {stopwatch.ElapsedMilliseconds}ms");

2. Check database query performance with SQL Profiler
3. Look for unnecessary object creation in loops
4. Consider caching frequently accessed data

Career Development Actions:

Build a learning routine:

Set aside time each week (even just 2-3 hours) for learning. Follow blogs like Scott Hanselman's or the official Microsoft Developer blogs.

Contribute to open source:

Find a C# open source project that interests you and fix a small bug or add a minor feature. This builds your portfolio and connects you with other developers.

Track your growth:

Keep a developer journal documenting challenges you've solved and skills you've learned. Review it monthly to see your progress.

Seek feedback:

Ask senior developers to review your code regularly. Accept criticism gracefully and apply what you learn to future work.

Practical Next Steps:

Choose one technical skill from the list to focus on this month
Set up a small project to practice this skill
Find a junior developer you can help mentor
Join C# communities on Reddit, Stack Overflow, or Discord
Schedule regular learning time on your calendar

Remember, becoming a senior developer happens gradually through consistent effort. Focus on continuous improvement rather than rushing to check off requirements. Each small step builds toward the expertise and perspective that defines a senior developer.

Building Scalable C# Web Apps When Requirements Are Unclear

syauqi fuadi — Sun, 13 Apr 2025 04:45:30 +0000

When starting a web app with unclear requirements, balance scalability and simplicity. Here’s how to do it in C# without overcomplicating:

1. Start Simple, but Plan for Growth

Build a modular core: Split your app into layers (e.g., Presentation, Business Logic, Data Access). Use interfaces and dependency injection (e.g., ASP.NET Core’s built-in DI) to keep components loosely coupled.

  // Example: Interface for flexibility
  public interface IUserService 
  {
      Task<User> GetUserAsync(int id);
  }

Avoid early optimization: Use a monolithic design first. Split into microservices only when traffic or complexity demands it.

2. Focus on Risky Areas

Identify parts likely to change (e.g., payment gateways, third-party integrations). Make these replaceable:

// Abstract payment processing
public interface IPaymentProcessor 
{
    Task ProcessPaymentAsync(decimal amount);
}

// Start with a simple implementation
public class BasicPaymentProcessor : IPaymentProcessor { ... }

Leave stable parts (e.g., user authentication) straightforward.

3. Use Proven Tools

Stick to common frameworks: ASP.NET Core, Entity Framework Core, and Azure services are battle-tested and scale well.
Avoid custom solutions for problems like caching or logging. Use built-in middleware or libraries (e.g., Serilog for logging).

4. Delay Decisions

Database choice: Start with SQL Server or PostgreSQL. Use the Repository Pattern to hide database details, making it easier to switch later.

  public class UserRepository : IUserRepository 
  {
      // Entity Framework Core example
      public async Task<User> GetByIdAsync(int id) 
      {
          return await _context.Users.FindAsync(id);
      }
  }

Infrastructure: Build for a single server first. Use cloud services (e.g., Azure App Service) to scale horizontally later.

5. Write Just Enough Tests

Cover critical workflows (e.g., payment processing) with unit tests. Avoid testing every small method early.
Use tools like xUnit or NUnit for maintainable tests.

6. Iterate and Refactor

Release a minimal viable product (MVP) first. Gather feedback before adding complex features.
Refactor when requirements stabilize. For example:
- Replace a basic IPaymentProcessor with a more robust solution.
- Split the monolith into microservices only if needed.

Avoid Over-Engineering

🚩 Red flags:

Adding layers (e.g., extra abstractions, “just-in-case” microservices) before they’re needed.
Building custom frameworks instead of using existing tools.
Over-designing databases for hypothetical future needs.

Key Takeaway

Build for today, design for tomorrow:

Keep code clean and modular.
Use abstractions only where change is likely.
Scale when the problem arises, not before.

By focusing on flexibility and simplicity, you’ll avoid over-engineering while staying ready to scale.

How to Modify/Update/Fix Existing C# Code Safely

syauqi fuadi — Sun, 13 Apr 2025 04:43:56 +0000

Here’s a simple guide to avoid new bugs when working with existing code:

1. Use Version Control

Create a new branch (e.g., git checkout -b fix/login-bug) before making changes.
This keeps the main code safe while you test your fixes.

2. Understand the Code First

Read the code carefully. Ask: What does this do? Why was it written this way?
Add comments or notes if parts are unclear (but don’t change anything yet).

3. Write Tests First

If tests already exist, run them to confirm current behavior.

Write unit tests (e.g., with xUnit/NUnit) for the code you’re fixing. Example:

 [Test]  
 public void CalculateTotal_ValidInput_ReturnsCorrectValue()  
 {  
     var result = Calculator.CalculateTotal(100, 0.2);  
     Assert.AreEqual(120, result);  
 }

Tests act as a safety net to catch unintended side effects.

4. Make Small Changes

Break big tasks into tiny steps (e.g., fix one bug at a time).
Test after every small change to catch issues early.

5. Use Tools to Spot Problems

Static analyzers (like Roslyn or ReSharper) highlight potential errors.

Enable warnings as errors in your project:

 <PropertyGroup>  
   <TreatWarningsAsErrors>true</TreatWarningsAsErrors>  
 </PropertyGroup>

6. Refactor Safely

Use your IDE’s tools (e.g., Visual Studio’s Rename or Extract Method) to avoid manual errors.
Follow SOLID principles (e.g., split large classes into smaller ones).

7. Test Again After Changes

Re-run all tests (old and new) to ensure nothing broke.
Test manually if automated tests don’t cover everything.

8. Review Code with Your Team

Ask a teammate to review your changes. Fresh eyes spot mistakes faster.

9. Update Documentation

If your change affects how the code works, update comments, READMEs, or wikis.

10. Monitor After Deployment

Use logging (e.g., Serilog) or monitoring tools (e.g., Application Insights) to catch issues in production.

Golden Rule:

Always ask, “Could this change break something else?”

Test early, test often, and keep changes small and clear. 🚀

How to Transition to Test-Driven Development (TDD) as a C# Developer

syauqi fuadi — Sun, 13 Apr 2025 04:42:08 +0000

TDD (Test-Driven Development) means writing tests before writing code. It helps you build reliable, clean code. Here’s a simple step-by-step guide with examples:

Step 1: Set Up a Test Project

Create a test project in your C# solution (e.g., using xUnit or MSTest).

Example:

dotnet new xunit -n MyProject.Tests
dotnet add MyProject.Tests reference MyProject

Step 2: Follow the Red-Green-Refactor Cycle

Red: Write a failing test.

Green: Write minimal code to pass the test.

Refactor: Improve code without breaking tests.

Example: Building a Calculator

Step 2.1: Red Phase

Write a test for an Add method that doesn’t exist yet:

// In MyProject.Tests/CalculatorTests.cs
public class CalculatorTests
{
    [Fact]
    public void Add_TwoNumbers_ReturnsSum()
    {
        // Arrange
        var calculator = new Calculator();

        // Act
        int result = calculator.Add(2, 3);

        // Assert
        Assert.Equal(5, result);
    }
}

This test will fail because Calculator and Add don’t exist yet.

Step 2.2: Green Phase

Write the simplest code to pass the test:

// In MyProject/Calculator.cs
public class Calculator
{
    public int Add(int a, int b)
    {
        return 0; // Temporary code (test will still fail)
    }
}

Run the test again. It fails because Add(2, 3) returns 0, not 5. Fix it:

public int Add(int a, int b)
{
    return a + b; // Now the test passes
}

Step 2.3: Refactor Phase

Improve code without changing behavior. For example:

// Add input validation (optional refactor)
public int Add(int a, int b)
{
    if (a < 0 || b < 0)
        throw new ArgumentException("Numbers must be non-negative");

    return a + b;
}

Update tests to cover new cases (e.g., test for invalid inputs).

Step 3: Repeat for New Features

Add more tests for other features (e.g., Subtract, Multiply):

[Fact]
public void Subtract_TwoNumbers_ReturnsDifference()
{
    var calculator = new Calculator();
    int result = calculator.Subtract(5, 3);
    Assert.Equal(2, result);
}

Write the Subtract method to pass this test.

Tips for Success

Start Small: Focus on one feature at a time.
Test Edge Cases: Test invalid inputs, empty values, etc.
Use Mocking: For dependencies (e.g., databases), use libraries like Moq.
Run Tests Often: Use dotnet test frequently.

Common Pitfalls to Avoid

Writing too many tests at once.
Skipping the refactor phase.
Testing implementation details (focus on behavior instead).

By practicing TDD, you’ll write cleaner code and catch bugs early. Start with simple projects and gradually tackle more complex scenarios! 🚀

Clean Architecture and SOLID Principles for C# Developers

syauqi fuadi — Mon, 07 Apr 2025 08:07:21 +0000

Introduction:

Clean Architecture and SOLID principles help us build better software that's easier to change, test, and maintain. This guide explains these concepts using simple language and real C# examples.

SOLID Principles in Real Life:

SOLID is a set of five principles that help make your code more flexible and less likely to break when changes happen.

Single Responsibility Principle (SRP):

Each class should do just one job. This makes code easier to understand and change.

Bad Example:

public class OrderProcessor
{
    public void ProcessOrder(Order order)
    {
        // Validate order
        if (order.Items.Count == 0)
            throw new Exception("Order has no items");

        // Calculate total
        decimal total = 0;
        foreach (var item in order.Items)
            total += item.Price * item.Quantity;

        // Save to database
        using (var connection = new SqlConnection("connection-string"))
        {
            // Database code here
        }

        // Send confirmation email
        SmtpClient client = new SmtpClient();
        client.Send("store@example.com", order.CustomerEmail, "Order Confirmation", "Your order is confirmed");
    }
}

Better Example:

public class OrderValidator
{
    public bool Validate(Order order) => order.Items.Count > 0;
}

public class OrderCalculator
{
    public decimal CalculateTotal(Order order)
    {
        decimal total = 0;
        foreach (var item in order.Items)
            total += item.Price * item.Quantity;
        return total;
    }
}

public class OrderRepository
{
    public void Save(Order order)
    {
        // Database code here
    }
}

public class EmailService
{
    public void SendOrderConfirmation(Order order)
    {
        // Email sending code here
    }
}

public class OrderProcessor
{
    private readonly OrderValidator _validator;
    private readonly OrderCalculator _calculator;
    private readonly OrderRepository _repository;
    private readonly EmailService _emailService;

    // Constructor with dependencies

    public void ProcessOrder(Order order)
    {
        if (!_validator.Validate(order))
            throw new Exception("Invalid order");

        order.Total = _calculator.CalculateTotal(order);
        _repository.Save(order);
        _emailService.SendOrderConfirmation(order);
    }
}

Open/Closed Principle (OCP):

Classes should be open for extension but closed for modification. Add new features by creating new code, not changing existing code.

// Before OCP
public class DiscountCalculator
{
    public decimal ApplyDiscount(Order order, string customerType)
    {
        if (customerType == "Regular")
            return order.Total * 0.05m;
        else if (customerType == "Premium")
            return order.Total * 0.10m;
        return 0;
    }
}

// After OCP
public interface IDiscountStrategy
{
    decimal ApplyDiscount(Order order);
}

public class RegularCustomerDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(Order order) => order.Total * 0.05m;
}

public class PremiumCustomerDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(Order order) => order.Total * 0.10m;
}

// Now when we need to add a new discount type, we just create a new class
public class GoldCustomerDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(Order order) => order.Total * 0.15m;
}

Liskov Substitution Principle (LSP):

If a function uses a base class, it should be able to use any of its derived classes without knowing it.

// Violating LSP
public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }

    public int Area() => Width * Height;
}

public class Square : Rectangle
{
    public override int Width
    {
        get => base.Width;
        set { base.Width = value; base.Height = value; }
    }

    public override int Height
    {
        get => base.Height;
        set { base.Width = value; base.Height = value; }
    }
}

// Code that breaks when using a Square:
Rectangle r = new Square();
r.Width = 5;
r.Height = 10;
// Area should be 50, but for Square it's 100!

// Following LSP - use a different approach
public interface IShape
{
    int Area();
}

public class Rectangle : IShape
{
    public int Width { get; set; }
    public int Height { get; set; }
    public int Area() => Width * Height;
}

public class Square : IShape
{
    public int SideLength { get; set; }
    public int Area() => SideLength * SideLength;
}

Interface Segregation Principle (ISP):

Create small, specific interfaces rather than large, general-purpose ones. Classes shouldn't be forced to implement methods they don't use.

// Bad approach - one large interface
public interface IReportGenerator
{
    void GeneratePdf();
    void GenerateExcel();
    void GenerateJson();
    void SendEmail();
    void PrintReport();
}

// Better approach - segregated interfaces
public interface IPdfReportGenerator
{
    void GeneratePdf();
}

public interface IExcelReportGenerator
{
    void GenerateExcel();
}

public interface IJsonReportGenerator
{
    void GenerateJson();
}

public interface IEmailSender
{
    void SendEmail();
}

public interface IPrinter
{
    void PrintReport();
}

// Now classes can implement only what they need
public class SalesReport : IPdfReportGenerator, IEmailSender
{
    public void GeneratePdf() { /* implementation */ }
    public void SendEmail() { /* implementation */ }
}

Dependency Inversion Principle (DIP):

High-level modules should not depend on low-level modules. Both should depend on abstractions.

// Bad approach - direct dependency
public class NotificationService
{
    public void SendNotification(string message)
    {
        var emailSender = new EmailSender();
        emailSender.SendEmail("user@example.com", message);
    }
}

// Better approach - dependency inversion
public interface IMessageSender
{
    void SendMessage(string to, string message);
}

public class EmailSender : IMessageSender
{
    public void SendMessage(string to, string message)
    {
        // Send email implementation
    }
}

public class SmsSender : IMessageSender
{
    public void SendMessage(string to, string message)
    {
        // Send SMS implementation
    }
}

public class NotificationService
{
    private readonly IMessageSender _messageSender;

    public NotificationService(IMessageSender messageSender)
    {
        _messageSender = messageSender;
    }

    public void SendNotification(string to, string message)
    {
        _messageSender.SendMessage(to, message);
    }
}

Clean Architecture Layers:

Clean Architecture divides your application into layers with clear responsibilities. Each inner layer doesn't know about outer layers.

Domain Layer:

This is the core of your application containing business entities, rules, and logic.

public class Order
{
    public int Id { get; private set; }
    public List<OrderItem> Items { get; private set; } = new List<OrderItem>();
    public decimal Total { get; private set; }
    public OrderStatus Status { get; private set; }

    public void AddItem(Product product, int quantity)
    {
        var item = new OrderItem(product, quantity);
        Items.Add(item);
        CalculateTotal();
    }

    private void CalculateTotal()
    {
        Total = Items.Sum(item => item.Subtotal);
    }

    public void Submit()
    {
        // Business rule: Can't submit empty orders
        if (!Items.Any())
            throw new DomainException("Cannot submit empty order");

        Status = OrderStatus.Submitted;
    }
}

public class OrderItem
{
    public Product Product { get; }
    public int Quantity { get; }
    public decimal Subtotal => Product.Price * Quantity;

    public OrderItem(Product product, int quantity)
    {
        if (quantity <= 0)
            throw new DomainException("Quantity must be positive");

        Product = product;
        Quantity = quantity;
    }
}

public enum OrderStatus
{
    Draft,
    Submitted,
    Processed,
    Shipped,
    Delivered,
    Cancelled
}

Application Layer:

Contains application-specific business rules. It coordinates the flow between the domain and infrastructure.

public interface IOrderRepository
{
    Task<Order> GetByIdAsync(int id);
    Task SaveAsync(Order order);
}

public class SubmitOrderUseCase
{
    private readonly IOrderRepository _orderRepository;
    private readonly IEmailService _emailService;

    public SubmitOrderUseCase(
        IOrderRepository orderRepository,
        IEmailService emailService)
    {
        _orderRepository = orderRepository;
        _emailService = emailService;
    }

    public async Task SubmitOrderAsync(int orderId)
    {
        // Get the order from repository
        var order = await _orderRepository.GetByIdAsync(orderId);
        if (order == null)
            throw new NotFoundException($"Order {orderId} not found");

        // Apply domain logic
        order.Submit();

        // Save changes
        await _orderRepository.SaveAsync(order);

        // Send notification
        await _emailService.SendOrderConfirmationAsync(order);
    }
}

Infrastructure Layer:

Implements interfaces defined in the application layer. Handles database access, external APIs, file systems, etc.

public class SqlOrderRepository : IOrderRepository
{
    private readonly DbContext _dbContext;

    public SqlOrderRepository(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<Order> GetByIdAsync(int id)
    {
        return await _dbContext.Orders
            .Include(o => o.Items)
            .ThenInclude(i => i.Product)
            .FirstOrDefaultAsync(o => o.Id == id);
    }

    public async Task SaveAsync(Order order)
    {
        _dbContext.Update(order);
        await _dbContext.SaveChangesAsync();
    }
}

public class SmtpEmailService : IEmailService
{
    public async Task SendOrderConfirmationAsync(Order order)
    {
        // Implementation using SMTP client
    }
}

Presentation Layer:

This could be a Web API, MVC application, or any other UI. It depends on the Application layer.

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly SubmitOrderUseCase _submitOrderUseCase;

    public OrdersController(SubmitOrderUseCase submitOrderUseCase)
    {
        _submitOrderUseCase = submitOrderUseCase;
    }

    [HttpPost("{id}/submit")]
    public async Task<IActionResult> SubmitOrder(int id)
    {
        try
        {
            await _submitOrderUseCase.SubmitOrderAsync(id);
            return Ok();
        }
        catch (NotFoundException ex)
        {
            return NotFound(ex.Message);
        }
        catch (DomainException ex)
        {
            return BadRequest(ex.Message);
        }
    }
}

CQRS and MediatR:

CQRS (Command Query Responsibility Segregation) separates read operations (queries) from write operations (commands). MediatR helps implement this pattern by decoupling handlers from senders.

Commands (Write Operations):

public class CreateOrderCommand : IRequest<int>
{
    public string CustomerEmail { get; set; }
    public List<OrderItemDto> Items { get; set; }
}

public class CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, int>
{
    private readonly IOrderRepository _orderRepository;

    public CreateOrderCommandHandler(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public async Task<int> Handle(CreateOrderCommand request, CancellationToken cancellationToken)
    {
        var order = new Order { CustomerEmail = request.CustomerEmail };

        foreach (var item in request.Items)
        {
            var product = await _productRepository.GetByIdAsync(item.ProductId);
            order.AddItem(product, item.Quantity);
        }

        await _orderRepository.SaveAsync(order);
        return order.Id;
    }
}

Queries (Read Operations):

public class GetOrderByIdQuery : IRequest<OrderDto>
{
    public int OrderId { get; set; }
}

public class GetOrderByIdQueryHandler : IRequestHandler<GetOrderByIdQuery, OrderDto>
{
    private readonly IOrderRepository _orderRepository;

    public GetOrderByIdQueryHandler(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public async Task<OrderDto> Handle(GetOrderByIdQuery request, CancellationToken cancellationToken)
    {
        var order = await _orderRepository.GetByIdAsync(request.OrderId);

        if (order == null)
            return null;

        // Map domain entity to DTO
        return new OrderDto
        {
            Id = order.Id,
            CustomerEmail = order.CustomerEmail,
            Total = order.Total,
            Status = order.Status.ToString(),
            Items = order.Items.Select(i => new OrderItemDto
            {
                ProductId = i.Product.Id,
                ProductName = i.Product.Name,
                Quantity = i.Quantity,
                UnitPrice = i.Product.Price,
                Subtotal = i.Subtotal
            }).ToList()
        };
    }
}

Controller Using MediatR:

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly IMediator _mediator;

    public OrdersController(IMediator mediator)
    {
        _mediator = mediator;
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<OrderDto>> GetOrder(int id)
    {
        var query = new GetOrderByIdQuery { OrderId = id };
        var result = await _mediator.Send(query);

        if (result == null)
            return NotFound();

        return Ok(result);
    }

    [HttpPost]
    public async Task<ActionResult<int>> CreateOrder(CreateOrderCommand command)
    {
        var orderId = await _mediator.Send(command);
        return CreatedAtAction(nameof(GetOrder), new { id = orderId }, orderId);
    }
}

Real-World Example: E-commerce Order System

Let's see how all these concepts come together in a real-world e-commerce application:

Domain Layer Example:

public class Product
{
    public int Id { get; private set; }
    public string Name { get; private set; }
    public decimal Price { get; private set; }
    public int StockQuantity { get; private set; }

    public bool IsInStock(int quantity) => StockQuantity >= quantity;

    public void ReduceStock(int quantity)
    {
        if (!IsInStock(quantity))
            throw new DomainException("Not enough stock");

        StockQuantity -= quantity;
    }
}

public class Order
{
    // Domain entities and business rules as shown earlier
}

Application Layer Example:

// Using CQRS with MediatR

// Command
public class PlaceOrderCommand : IRequest<int>
{
    public string CustomerEmail { get; set; }
    public List<OrderItemRequest> Items { get; set; }
}

public class OrderItemRequest
{
    public int ProductId { get; set; }
    public int Quantity { get; set; }
}

// Command Handler
public class PlaceOrderCommandHandler : IRequestHandler<PlaceOrderCommand, int>
{
    private readonly IOrderRepository _orderRepository;
    private readonly IProductRepository _productRepository;
    private readonly IUnitOfWork _unitOfWork;

    public PlaceOrderCommandHandler(
        IOrderRepository orderRepository,
        IProductRepository productRepository,
        IUnitOfWork unitOfWork)
    {
        _orderRepository = orderRepository;
        _productRepository = productRepository;
        _unitOfWork = unitOfWork;
    }

    public async Task<int> Handle(PlaceOrderCommand request, CancellationToken cancellationToken)
    {
        var order = new Order { CustomerEmail = request.CustomerEmail };

        foreach (var item in request.Items)
        {
            var product = await _productRepository.GetByIdAsync(item.ProductId);

            if (product == null)
                throw new NotFoundException($"Product {item.ProductId} not found");

            if (!product.IsInStock(item.Quantity))
                throw new DomainException($"Not enough stock for product {product.Name}");

            product.ReduceStock(item.Quantity);
            order.AddItem(product, item.Quantity);
        }

        order.Submit();

        _orderRepository.Add(order);
        await _unitOfWork.SaveChangesAsync();

        return order.Id;
    }
}

Infrastructure Layer Example:

public class AppDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }
    public DbSet<OrderItem> OrderItems { get; set; }
    public DbSet<Product> Products { get; set; }

    // Configuration here
}

public class EfOrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;

    public EfOrderRepository(AppDbContext context)
    {
        _context = context;
    }

    public void Add(Order order)
    {
        _context.Orders.Add(order);
    }

    public async Task<Order> GetByIdAsync(int id)
    {
        return await _context.Orders
            .Include(o => o.Items)
            .ThenInclude(i => i.Product)
            .FirstOrDefaultAsync(o => o.Id == id);
    }
}

public class EfUnitOfWork : IUnitOfWork
{
    private readonly AppDbContext _context;

    public EfUnitOfWork(AppDbContext context)
    {
        _context = context;
    }

    public async Task SaveChangesAsync()
    {
        await _context.SaveChangesAsync();
    }
}

API Layer Example:

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly IMediator _mediator;

    public OrdersController(IMediator mediator)
    {
        _mediator = mediator;
    }

    [HttpPost]
    public async Task<ActionResult<int>> PlaceOrder(PlaceOrderCommand command)
    {
        try
        {
            var orderId = await _mediator.Send(command);
            return Ok(orderId);
        }
        catch (NotFoundException ex)
        {
            return NotFound(ex.Message);
        }
        catch (DomainException ex)
        {
            return BadRequest(ex.Message);
        }
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<OrderDto>> GetOrder(int id)
    {
        var query = new GetOrderByIdQuery { OrderId = id };
        var order = await _mediator.Send(query);

        if (order == null)
            return NotFound();

        return Ok(order);
    }
}

Benefits of This Approach:

Easier Testing - Each layer can be tested independently
Maintainability - Changes in one layer don't affect others
Flexibility - Can replace infrastructure components without changing business logic
Scalability - Can optimize read and write operations separately with CQRS
Team Collaboration - Different teams can work on different layers

Summary:

By following Clean Architecture and SOLID principles, you create a system that's organized, flexible, and easy to maintain. Using CQRS with MediatR helps separate read and write operations, making your code even cleaner. The real benefit shows when requirements change - you'll be able to adapt your application without rewriting everything.

LINQ Internals and Pitfalls for C# Developers

syauqi fuadi — Mon, 07 Apr 2025 07:44:01 +0000

Understanding IEnumerable vs IQueryable:

In LINQ, both IEnumerable<T> and IQueryable<T> let you work with collections of data, but they behave differently behind the scenes.

IEnumerable:

Works with in-memory data like lists, arrays, or collections
Processes data in your application's memory (client-side)
Simple to use but can be inefficient with large datasets

// IEnumerable example
List<Customer> customers = GetAllCustomers();
var goldCustomers = customers.Where(c => c.Type == "Gold");
// The entire customers list is loaded into memory first

IQueryable:

Designed for remote data sources like databases
Translates your C# expressions into the data source's language (like SQL)
More efficient with large datasets as filtering happens at the source

// IQueryable example
IQueryable<Customer> customers = dbContext.Customers;
var goldCustomers = customers.Where(c => c.Type == "Gold");
// Translates to SQL: SELECT * FROM Customers WHERE Type = 'Gold'

How Deferred Execution Works:

LINQ uses "lazy evaluation" - queries aren't executed when you write them, but only when you actually need the results.

// This just creates a query definition, nothing executes yet
var expensiveProducts = products.Where(p => p.Price > 100);

// The query only executes now, when we start using the results
foreach (var product in expensiveProducts)
{
    Console.WriteLine(product.Name);
}

This is powerful because:

You build queries in steps without repeatedly processing data
The data source is only accessed when needed
You can create reusable query templates

Query execution is triggered when you:

Loop through results with foreach
Call methods like ToList(), ToArray(), First(), Count()
Use aggregate functions like Sum(), Average(), etc.

Avoiding Performance Issues:

Problem 1: Multiple Enumerations

When you enumerate the same query multiple times, it re-executes each time:

// BAD PRACTICE
var products = dbContext.Products.Where(p => p.Category == "Electronics");

// This executes the query once
if (products.Any())
{
    // This executes the SAME query again!
    foreach (var product in products)
    {
        Console.WriteLine(product.Name);
    }

    // And here it executes a THIRD time!
    Console.WriteLine($"Total products: {products.Count()}");
}

Better approach:

// GOOD PRACTICE
// Execute once and store results
var products = dbContext.Products
    .Where(p => p.Category == "Electronics")
    .ToList();  // Query executes here and results are stored

if (products.Any())
{
    foreach (var product in products)
    {
        Console.WriteLine(product.Name);
    }

    Console.WriteLine($"Total products: {products.Count}");
}

Problem 2: Complex Query Chains

Complex LINQ chains can be hard to understand and maintain:

// Complex and inefficient
var result = customers
    .Where(c => c.Orders.Any())
    .SelectMany(c => c.Orders)
    .Where(o => o.Total > 100)
    .OrderBy(o => o.Date)
    .Select(o => new { o.Id, o.Total, CustomerName = o.Customer.Name });

Better approach:

// Break it down into meaningful steps
var customersWithOrders = customers.Where(c => c.Orders.Any());
var largeOrders = customersWithOrders
    .SelectMany(c => c.Orders)
    .Where(o => o.Total > 100);
var orderedResults = largeOrders
    .OrderBy(o => o.Date)
    .Select(o => new { o.Id, o.Total, CustomerName = o.Customer.Name })
    .ToList();  // Execute once and store

Problem 3: N+1 Query Problem

This happens when you load a collection and then access related entities in a loop:

// BAD: Causes N+1 queries (1 for orders, N for customers)
var orders = dbContext.Orders.Take(100).ToList();
foreach (var order in orders)
{
    // This triggers a separate database query for EACH order!
    Console.WriteLine($"Order #{order.Id} by {order.Customer.Name}");
}

Better approach:

// GOOD: Use Include() to load related data in a single query
var orders = dbContext.Orders
    .Include(o => o.Customer)  // Load customers with orders
    .Take(100)
    .ToList();

foreach (var order in orders)
{
    // No additional queries needed; data already loaded
    Console.WriteLine($"Order #{order.Id} by {order.Customer.Name}");
}

Real-World Example: Product Catalog Filtering

Let's see how these concepts apply to a product catalog filter:

// Common real-world scenario
public List<ProductViewModel> GetFilteredProducts(
    string category = null,
    decimal? minPrice = null,
    decimal? maxPrice = null,
    string sortBy = "name")
{
    // Start with IQueryable
    IQueryable<Product> query = dbContext.Products;

    // Build query conditionally
    if (!string.IsNullOrEmpty(category))
        query = query.Where(p => p.Category == category);

    if (minPrice.HasValue)
        query = query.Where(p => p.Price >= minPrice.Value);

    if (maxPrice.HasValue)
        query = query.Where(p => p.Price <= maxPrice.Value);

    // Apply sorting
    query = sortBy.ToLower() switch
    {
        "price" => query.OrderBy(p => p.Price),
        "date" => query.OrderByDescending(p => p.CreatedDate),
        _ => query.OrderBy(p => p.Name)
    };

    // Execute query and map to view model
    return query
        .Select(p => new ProductViewModel
        {
            Id = p.Id,
            Name = p.Name,
            Price = p.Price,
            Category = p.Category,
            InStock = p.StockQuantity > 0
        })
        .ToList();  // Query executes here
}

This example shows good practices:

Using IQueryable for database queries
Building the query in stages without executing until needed
Converting to a List only once at the end
Using projection (Select) to get only the data needed

By understanding these LINQ internals, you can write code that's not just functional but also performs well even with large datasets.

Building a High-Performance Event-Driven App with .NET and a Database

syauqi fuadi — Sat, 05 Apr 2025 13:45:49 +0000

Event-driven architectures (EDA) are powerful for building scalable systems that handle complex workflows. But what if you need to build such a system using only a .NET application and a database—no message brokers like Kafka or RabbitMQ? This article explains how to design a robust, event-driven app capable of handling heavy transaction loads, tracking all states, and automatically retrying failed steps.

Why Use a Database as an Event Store?

While dedicated message brokers offer advanced features, a database can act as a reliable event store for simpler scenarios. By storing events in a database table, you gain:

Persistence: Events survive app restarts.
Transaction tracking: Every step’s state is recorded.
Scalability: Databases like SQL Server or PostgreSQL handle high read/write loads.

Step 1: Designing the Database Schema

Create an Events table to store all transactions and their states:

CREATE TABLE Events (
    EventId UNIQUEIDENTIFIER PRIMARY KEY,
    EventType NVARCHAR(50) NOT NULL,
    Payload NVARCHAR(MAX), -- JSON data
    Status NVARCHAR(20) NOT NULL, -- Pending, Processing, Completed, Failed
    RetryCount INT DEFAULT 0,
    CreatedAt DATETIME DEFAULT GETDATE(),
    LastUpdated DATETIME DEFAULT GETDATE()
);

Status: Tracks progress through the pipeline (e.g., PaymentPending → InventoryChecked → Completed).
RetryCount: Limits retry attempts to avoid infinite loops.

Step 2: Building the .NET Application

Event Producer

Any part of your app (e.g., an API endpoint) can insert events into the Events table:

public async Task CreateEvent(string eventType, string payload)
{
    var newEvent = new Event
    {
        EventId = Guid.NewGuid(),
        EventType = eventType,
        Payload = payload,
        Status = "Pending"
    };

    await _dbContext.Events.AddAsync(newEvent);
    await _dbContext.SaveChangesAsync();
}

Event Consumer (Background Worker)

Use a .NET BackgroundService to poll for pending events and process them:

public class EventProcessor : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            var pendingEvents = await _dbContext.Events
                .Where(e => e.Status == "Pending" && e.RetryCount < 3)
                .OrderBy(e => e.CreatedAt)
                .Take(100) // Batch size for load handling
                .ToListAsync();

            foreach (var event in pendingEvents)
            {
                try
                {
                    event.Status = "Processing";
                    await _dbContext.SaveChangesAsync();

                    await ProcessEvent(event); // Execute pipeline steps

                    event.Status = "Completed";
                    await _dbContext.SaveChangesAsync();
                }
                catch (Exception ex)
                {
                    event.Status = "Failed";
                    event.RetryCount++;
                    _logger.LogError(ex, "Event {EventId} failed", event.EventId);
                    await _dbContext.SaveChangesAsync();
                }
            }

            await Task.Delay(1000, stoppingToken); // Adjust polling interval
        }
    }
}

Step 3: Implementing the Processing Pipeline

Define a pipeline with multiple steps (e.g., validate payment → update inventory → send confirmation). Use a strategy pattern:

public interface IEventProcessor
{
    Task<bool> ProcessAsync(Event @event);
}

public class PaymentProcessor : IEventProcessor { ... }
public class InventoryProcessor : IEventProcessor { ... }

// In ProcessEvent method:
var processors = new Dictionary<string, IEventProcessor>
{
    { "PaymentPending", new PaymentProcessor() },
    { "InventoryUpdate", new InventoryProcessor() }
};

if (processors.TryGetValue(event.EventType, out var processor))
{
    await processor.ProcessAsync(event);
}
else
{
    throw new NotSupportedException($"Event type {event.EventType} not recognized.");
}

Step 4: Handling Failures and Retries

Auto-Retry: The background worker retries failed events (up to RetryCount limit).
Dead-Letter Queue: Move events with RetryCount >= 3 to a separate table for manual review.
Idempotency: Ensure each step can be retried safely (e.g., use unique IDs to avoid duplicate processing).

Performance Tips for Heavy Loads

Batching: Process events in batches to reduce database roundtrips.
Indexing: Add indexes on Status and CreatedAt for faster queries.
Concurrency Control: Use ROWVERSION or optimistic concurrency to prevent race conditions.
Async/Await: Avoid blocking threads during I/O operations.

Conclusion

By leveraging a database as an event store and a .NET BackgroundService, you can build a scalable, event-driven app without external dependencies. This approach ensures all transaction states are tracked, supports heavy loads through batching and async processing, and provides automatic retries for reliability. While not as fast as dedicated message brokers, it’s a practical solution for many business scenarios.

Need help optimizing your event-driven system? Share your use case, and let’s discuss! 🚀

Handling Transactions on Large Tables in High-Traffic C# Applications

syauqi fuadi — Sat, 05 Apr 2025 09:50:16 +0000

Working with large database tables in high-traffic environments can be challenging, especially when performing updates. As a C# developer, you need strategies to optimize transactions, reduce timeouts, and maintain performance. Here’s how to approach this problem.

1. Optimize Transactions

Transactions are critical for data consistency but can become bottlenecks.

Keep Transactions Short Minimize the time a transaction remains open. Split large operations into smaller batches (e.g., update 1,000 rows at a time).

  using (var transaction = connection.BeginTransaction())  
  {  
      for (int i = 0; i < totalRecords; i += batchSize)  
      {  
          var batch = GetBatchData(i, batchSize);  
          connection.Execute("UPDATE LargeTable SET Column = @Value WHERE Id = @Id", batch, transaction);  
      }  
      transaction.Commit();  
  }

Use Read Committed Snapshot Isolation (RCSI) Enable RCSI in SQL Server to reduce locking and blocking. This allows readers to see a consistent snapshot of data without blocking writers.

2. Tune Queries and Indexes

Slow queries are a common cause of timeouts.

Optimize Indexes

Ensure indexes exist on columns used in WHERE, JOIN, or ORDER BY clauses. Avoid over-indexing, as it slows down writes.
- Use SQL Server Execution Plans to identify missing indexes.
Filter and Batch Updates

Update only necessary columns and rows. Use WHERE clauses to target specific data.

  UPDATE LargeTable  
  SET Status = 'Processed'  
  WHERE Status = 'Pending' AND CreatedDate < DATEADD(DAY, -1, GETDATE());

3. Handle Timeouts Gracefully

Timeouts often occur due to resource contention or long-running queries.

Increase Command Timeout Adjust the timeout for specific operations in C#:

  using (var command = new SqlCommand(query, connection))  
  {  
      command.CommandTimeout = 120; // 120 seconds  
  }

Implement Retry Logic Use libraries like Polly to retry transient errors (e.g., deadlocks):

  var retryPolicy = Policy  
      .Handle<SqlException>(ex => ex.Number == 1205) // Deadlock error code  
      .WaitAndRetry(3, retryAttempt => TimeSpan.FromSeconds(2));  

  retryPolicy.Execute(() => UpdateLargeTable());

4. Scale and Maintain Tables

Partition Large Tables

Split tables into smaller partitions by date or category (e.g., monthly partitions). This reduces lock contention.
Archive Old Data

Move historical data to an archive table to keep the main table lean.
Update Statistics Regularly

Ensure the database optimizer has up-to-date statistics for efficient query plans.

5. Use Asynchronous Programming

For high-traffic apps, use async/await to avoid blocking threads:

public async Task UpdateRecordAsync(int id)  
{  
    using (var connection = new SqlConnection(connectionString))  
    {  
        await connection.ExecuteAsync(  
            "UPDATE LargeTable SET Column = @Value WHERE Id = @Id",  
            new { Value = "NewData", Id = id }  
        );  
    }  
}

Final Tips

Monitor Performance: Use tools like SQL Server Profiler or Application Insights to identify slow queries.
Test Under Load: Simulate high traffic to uncover bottlenecks before deployment.
Avoid Cursors: Use set-based operations instead of row-by-row processing.

By combining optimized code, smart database design, and proper error handling, you can maintain performance even when working with large tables in high-traffic C# applications.

How to Stress Test Your .NET Application: A C# Developer’s Guide

syauqi fuadi — Sat, 05 Apr 2025 09:39:12 +0000

Stress testing is a critical step to ensure your .NET application can handle heavy traffic, high user loads, or unexpected spikes without crashing. As a C# developer, you need to simulate real-world scenarios to find performance bottlenecks and improve reliability. Here’s a practical guide to stress testing your app.

1. Plan Your Stress Test

Before writing code, define your goals:

Target Load: How many users or requests should your app handle at once?
Key Metrics: Monitor response time, CPU/memory usage, database latency, and error rates.
Test Scenarios: Identify critical workflows (e.g., user login, payment processing).

2. Choose the Right Tools

Use tools that integrate well with .NET:

NBomber: A modern .NET framework for load testing. Write tests in C# and simulate thousands of virtual users.
Apache JMeter: A Java-based tool (works with .NET APIs) for creating complex test plans.
Visual Studio Enterprise: Built-in load testing features for web apps.

Example of a simple NBomber test:

var httpClient = new HttpClient();  
var scenario = Scenario.Create("Stress Test API", async context =>  
{  
    var response = await httpClient.GetAsync("https://yourapi.com/data");  
    return response.IsSuccessStatusCode ? Response.Ok() : Response.Fail();  
})  
.WithLoadSimulation(Simulation.Inject(rate: 100, interval: TimeSpan.FromSeconds(1), during: TimeSpan.FromMinutes(5)));  

NBomberRunner  
    .RegisterScenarios(scenario)  
    .Run();

3. Simulate Realistic Conditions

Scale Gradually: Start with a small load and increase it to avoid overwhelming the system.
Use Real Data: Test with production-like datasets to mimic actual database queries.
Test Dependencies: Include third-party services (e.g., payment gateways) or mock them if unavailable.

4. Monitor Performance

Track metrics during the test:

Application Insights: Integrate with Azure to monitor requests, exceptions, and dependencies.
dotnet-counters: A CLI tool to track CPU, memory, and GC activity in real time.

dotnet-counters monitor --process-id [PID] --counters System.Runtime

5. Analyze and Optimize

After the test:

Identify Bottlenecks: Slow database queries, memory leaks, or thread-blocking code.
Optimize Code: Use profiling tools like JetBrains dotTrace to find inefficient code.
Scale Resources: Adjust server capacity, database indexing, or caching (e.g., Redis).

6. Repeat and Automate

Stress testing isn’t a one-time task. Automate tests in your CI/CD pipeline to catch regressions early. Tools like GitHub Actions or Azure DevOps can run tests after each deployment.

Why Stress Testing Matters

Prevent Downtime: Avoid crashes during peak traffic (e.g., Black Friday sales).
Improve User Experience: Ensure fast response times even under load.
Save Costs: Optimize resource usage to reduce cloud hosting expenses.

By integrating stress testing into your workflow, you’ll build .NET applications that are both robust and scalable. Start small, iterate often, and always test like your app’s success depends on it—because it does!

Got questions? Share your stress testing tips or challenges in the comments below! 🚀

React Folder Component Architecture: A C# Developer’s Perspective

syauqi fuadi — Mon, 31 Mar 2025 22:50:31 +0000

As a C# developer, organizing code in a clear, scalable way is familiar—whether using layered architectures like MVC or modular patterns. React’s component-based approach offers similar goals but requires adapting to a different mindset. Here’s how React folder structures work, whether Next.js’s opinionated setup is ideal, and options to consider.

React Component Architecture Basics

In React, components are reusable building blocks (like C# classes or Razor components). However, structuring them can feel chaotic without guidelines. Common approaches include:

Grouping by File Type

   - /src  
     - /components  (e.g., Button, Header)  
     - /pages       (e.g., HomePage, ProfilePage)  
     - /hooks       (custom hooks)  
     - /utils       (helper functions)

Pros: Simple, easy for small projects.

Cons: Hard to scale; components lack context (like grouping unrelated C# models and controllers).

Feature-Based Folders

   - /src  
     - /features  
       - /authentication  
         - components (LoginForm, SignupButton)  
         - hooks      (useAuth)  
       - /dashboard  
         - components (Chart, StatsPanel)

Pros: Logical grouping (similar to C# modules or vertical slices). Easier maintenance.

Cons: Risk of duplication (e.g., reusable buttons buried in features).

Atomic Design Split components into atoms (smallest UI pieces), molecules, organisms, etc. Pros: Encourages reusability (like C# base classes). Cons: Overkill for simple apps; rigid for dynamic features.

Is Next.js’s Opinionated Structure the Best Choice?

Next.js enforces conventions like /pages or /app for routing, which can feel familiar to C# developers used to MVC’s predefined structures.

Pros:

Built-in Routing: Automatic page routing (like ASP.NET Core’s endpoint mapping).
Optimization: Server-side rendering (SSR), static site generation (SSG)—similar to Razor Pages but for React.
Less Configuration: Focus on features, not setup (like .NET templates).

Cons:

Flexibility Limits: Hard to customize if your project needs unique routing or state logic.
Learning Curve: New concepts (e.g., Server Components) require time.

When to Choose Next.js:

Full-stack apps needing SEO-friendly rendering.
Teams valuing convention over configuration (like using ASP.NET Core’s defaults).

Recommended Structure for C# Developers

A hybrid approach works well for most projects:

- /src  
  - /components  
    - /ui          (reusable atoms: buttons, inputs)  
    - /features    (feature-specific components)  
  - /lib           (C#-like utilities, API clients)  
  - /hooks         (global hooks like useFetch)  
  - /pages or /app (Next.js routing)

Pros:

Balances reusability and feature context.
Feels intuitive if you’re used to layered .NET architectures.

Cons:

Requires discipline to avoid mixing UI and logic.

Conclusion

Next.js’s opinionated structure is excellent for full-stack apps requiring SSR/SSG, much like ASP.NET Core simplifies backend logic. However, for smaller projects or teams wanting full control, a custom React setup with feature-based folders might be better. As a C# developer, lean on patterns you know—modularity, separation of concerns—and adapt them to React’s component-driven world.

DEV Community: syauqi fuadi

From C# to TypeScript: Your Cozy Guide to Microsoft’s Dynamic Duo

Why TypeScript Feels Like Home

1. “Wait, I’ve Seen This Before!” – Static Typing

2. OOP Soulmates: Classes & Interfaces

3. Generics: Your Code’s Reusable Blueprint

4. Async/Await: Same Superpower, New Playground

Where TypeScript Takes a Different Path

1. Runtime Reality Check

2. Structural Typing: Shape Over Name

3. The Wild any Card

4. Tooling: npm > NuGet

Your Cheat Sheet for a Smooth Transition

Final Thought: Why You’ll Love TypeScript

Choosing a Front-End for .NET Development

1. Traditional HTML/JavaScript + Lightweight Libraries

Example 1: HTMX + .NET API

Example 2: Alpine.js + Razor Pages

2. Modern Frameworks (React/Vue/Angular)

Example 1: React + .NET Web API

Example 2: Vue + .NET

3. Blazor (C# on the Front-End)

Example: Blazor Component

When to Use What?

How to Become a Senior C# Developer: Action Steps

Master C# Technical Skills:

Build System Architecture Knowledge:

Develop Professional Skills:

Solving Complex Problems:

Career Development Actions:

Practical Next Steps:

Building Scalable C# Web Apps When Requirements Are Unclear

1. Start Simple, but Plan for Growth

2. Focus on Risky Areas

3. Use Proven Tools

4. Delay Decisions

5. Write Just Enough Tests

6. Iterate and Refactor

Avoid Over-Engineering

Key Takeaway

How to Modify/Update/Fix Existing C# Code Safely

1. Use Version Control

2. Understand the Code First

3. Write Tests First

4. Make Small Changes

5. Use Tools to Spot Problems

6. Refactor Safely

7. Test Again After Changes

8. Review Code with Your Team

9. Update Documentation

10. Monitor After Deployment

How to Transition to Test-Driven Development (TDD) as a C# Developer

Step 1: Set Up a Test Project

Step 2: Follow the Red-Green-Refactor Cycle

Example: Building a Calculator

Step 3: Repeat for New Features

Tips for Success

Common Pitfalls to Avoid

Clean Architecture and SOLID Principles for C# Developers

Introduction:

SOLID Principles in Real Life:

Single Responsibility Principle (SRP):

Open/Closed Principle (OCP):

Liskov Substitution Principle (LSP):

Interface Segregation Principle (ISP):

Dependency Inversion Principle (DIP):

Clean Architecture Layers:

Domain Layer:

Application Layer:

Infrastructure Layer:

Presentation Layer:

CQRS and MediatR:

Commands (Write Operations):

Queries (Read Operations):

Controller Using MediatR:

Real-World Example: E-commerce Order System

Domain Layer Example:

Application Layer Example:

Infrastructure Layer Example:

API Layer Example:

3. The Wild `any` Card