DEV Community: Mo

Claude Opus 4.6 vs. GPT 5.4

Mo — Sun, 29 Mar 2026 17:10:27 +0000

Claude Opus 4.6 vs. GPT 5.4: My Take as a C#/.NET Dev on AI Coding Companions

Alright team, let's talk AI. As a senior engineer who's spent more years than I care to admit wrangling C# and .NET, I've seen my fair share of "game-changing" tech. Most of it is just hype. But these new-gen LLMs? They're different. We're talking about legitimate productivity boosters, especially when you're staring down a tricky bug or architecting a new microservice.

Lately, I've been putting the big two — Claude Opus 4.6 and GPT 5.4 — through their paces specifically for coding tasks. The question isn't if they're useful, but which one to bring to the fight, or if we should be thinking "both." Let's dive into my real-world experiences.

The Setup: My C#/.NET AI Playground

Before we get into the nitty-gritty, a quick word on my testing environment. I wasn't just asking them to write "Hello World." I was throwing real-world problems at them: building complex LINQ queries, designing a robust API controller, refactoring legacy code, even trying to get them to write xUnit tests for some tricky asynchronous logic.

I wanted to see how they handled:

Context: Can they keep track of a larger codebase or conversation?
Precision: Do they generate code that actually compiles and runs correctly the first time?
Nuance: Can they understand why I'm asking for something, not just what?
Debugging: How good are they at finding issues in their own code or mine?

GPT 5.4: The Speedy Generalist with a Few Surprises

GPT 5.4 feels like that incredibly bright junior developer who's read every programming book but sometimes misses the specific context of our project. It's fast, incredibly broad in its knowledge, and often provides surprisingly elegant solutions right out of the gate.

When I needed boilerplate code for a new DbContext or a standard ASP.NET Core controller, GPT 5.4 was lightning-fast and usually spot-on. It's fantastic for generating common design patterns or even suggesting different approaches to a problem.

Where it Shines:

Broad Knowledge Base: If it's a common C# pattern, a widely used .NET library, or a general algorithm, GPT 5.4 knows it.
Code Generation Speed: It often generates long code blocks quickly, perfect for getting a first draft down.
Exploration: Great for brainstorming different ways to solve a problem or exploring new libraries.

Where I Pump the Brakes:
Sometimes, GPT 5.4 can be a bit too confident. It occasionally generates plausible-looking code that has subtle bugs, or it might make assumptions about my project that aren't true. I've also found it can "forget" earlier parts of our conversation if the thread gets too long. It's like it gets distracted by the next shiny coding problem.

Claude Opus 4.6: The Meticulous Architect, Slow and Steady

Claude Opus 4.6, on the other hand, feels more like a seasoned architect. It's often slower to respond, but its answers tend to be incredibly thoughtful, detailed, and deeply contextual. It seems to "think" more before responding, often asking clarifying questions or laying out its reasoning step-by-step.

For complex refactoring tasks, or when I was trying to optimize a specific piece of asynchronous code for performance, Claude truly stood out. It provided not just the code, but the rationale behind the choices, often citing best practices or potential pitfalls. It felt like pair programming with someone who meticulously considers every angle.

Where it Shines:

Contextual Understanding: It maintains context over very long conversations, making it excellent for multi-step tasks or complex debugging.
Deep Reasoning: Its explanations are often superb, breaking down complex problems and justifying its code choices.
Fewer Hallucinations: I've found it to be more reliable in generating correct, runnable code without subtle errors. It double-checks its work, which is invaluable.
Refactoring & Debugging: Excellent at identifying issues in existing code and suggesting robust improvements.

Where I Feel the Pinch:
The speed. Sometimes, when you just need a quick IEnumerable extension method or a simple DI setup, waiting for Claude's detailed explanation can feel a bit overkill. It's not a rapid-fire code generator in the same way GPT 5.4 can be.

The Verdict: Don't Choose, Combine!

After weeks of real-world use, my conclusion is clear: you don't have to pick just one. These aren't competitors; they're complementary tools in a modern software engineer's arsenal.

Think of it this way:

Reach for GPT 5.4 when:
- You need rapid prototyping or boilerplate generation.
- You're exploring new libraries or frameworks and need quick examples.
- You're stuck on a common problem and need a few different potential solutions fast.
- You need simple, isolated code snippets.
Reach for Claude Opus 4.6 when:
- You're working on complex architectural decisions or refactoring significant parts of your codebase.
- You need detailed explanations, best practices, and a deeper understanding of why certain code is structured a certain way.
- You're debugging persistent, tricky issues and need a methodical, logical approach.
- You have a long, ongoing conversation about a specific problem and need the AI to maintain deep context.

I often start with GPT 5.4 for initial drafts or quick ideas. Then, if I hit a wall, or if the problem requires more nuanced reasoning, I'll port the conversation (or at least the core problem) over to Claude Opus 4.6 for a more in-depth architectural review or a meticulous debugging session. It’s like having a brilliant junior dev for the grunt work and an experienced architect for the heavy lifting.

Your AI Pair Programming Partner(s)

Adopting these tools isn't about replacing engineers; it's about augmenting our capabilities. It's like having a super-powered pair programmer who never gets tired and has read the internet. For us C# and .NET folks, understanding the strengths of both Claude Opus 4.6 and GPT 5.4 means we can write better code, faster, and with fewer headaches.

What are your experiences? Have you found one to be clearly superior for your specific tech stack, or are you also seeing the value in a multi-model approach? Let me know in the comments!

C# Keeps Getting Better: My Favourite Modern Language Features

Mo — Sat, 28 Mar 2026 11:48:16 +0000

If you've been coding in C# for a while, you know it's a language that refuses to sit still. Every new version brings a fresh set of tools, and honestly, as someone who's been wrangling .NET for years, it's pretty exciting to see how much more expressive, concise, and just plain fun C# has become. Gone are the days of endless boilerplate for simple tasks!

Let's dive into some of the features that have genuinely changed how I approach C# development.

Streamlining Your Code: Less Ceremony, More Action!

One of the biggest shifts in recent C# versions has been a strong push towards reducing boilerplate. We're all busy, right? Why type more when you can say the same thing with less?

Top-Level Statements: Kickstarting Your Apps

Remember when even a simple "Hello World" console app needed a namespace, a class, and a static void Main(string[] args)? It felt a bit heavy for quick scripts or learning examples. Well, say hello to top-level statements!

Now, your entire program can look like this:

// Program.cs
Console.WriteLine("Hello, modern C#!");

// You can even use async/await directly
await Task.Delay(100);
Console.WriteLine("Waiting is over!");

This is fantastic for small utilities, Azure Functions, or just getting an idea off the ground without the cognitive load of a full class structure. It makes C# feel much more scripting-friendly.

Global Using Directives: De-cluttering Your Files

How many times have you scrolled past a dozen using statements at the top of every file? System, System.Collections.Generic, System.Linq, Microsoft.EntityFrameworkCore... the list goes on.

global using directives let you declare these common using statements once for your entire project. Just drop them into a file (often GlobalUsings.cs or Usings.cs), and they're available everywhere.

// GlobalUsings.cs
global using System;
global using System.Collections.Generic;
global using System.Linq;
global using Microsoft.EntityFrameworkCore;
// ...and so on

The difference this makes in larger projects is immense. Your individual files become cleaner, focusing purely on the code within. No more endless scrolling past using blocks!

Embracing Immutability: Records & `init` Setters

Immutability is a huge win for robust, predictable software. When an object's state can't change after it's created, you eliminate entire classes of bugs related to unexpected side effects. C# has made it a first-class citizen with records and init setters.

Record Types: The Data-First Class

Records are essentially classes (or structs) designed for immutable data models. They come with a ton of goodies out of the box, like value-based equality, concise syntax, and non-destructive mutation (with expressions).

Imagine you're defining a Data Transfer Object (DTO) or an entity:

// Old way (class) - lots of boilerplate for immutability, equality, and ToString
public class Product
{
    public int Id { get; }
    public string Name { get; }
    public decimal Price { get; }

    public Product(int id, string name, decimal price)
    {
        Id = id;
        Name = name;
        Price = price;
    }
    // Need to override Equals, GetHashCode, ToString manually...
}

// New way (record) - concise, immutable by default, value equality
public record Product(int Id, string Name, decimal Price);

That's right, a single line! Records are perfect for scenarios where you just need to represent data. They save you from writing mountains of boilerplate for Equals, GetHashCode, and ToString, and they promote a functional style of programming.

`init` Setters: Immutable Properties, Flexible Creation

Even with regular classes, init setters provide a powerful way to ensure properties can only be set during object initialisation, enforcing immutability after creation.

public class UserProfile
{
    public int Id { get; init; } // Can only be set during object creation
    public string Username { get; init; }
    public DateTime RegisteredDate { get; init; } = DateTime.UtcNow; // Default value also works

    // Usage
    var user = new UserProfile { Id = 1, Username = "devfriend" };
    // user.Id = 2; // Error: Init-only setter cannot be used here
}

This gives you the best of both worlds: object initialiser syntax for easy construction, and immutability once the object is fully formed. Super handy for configuration objects or read-only view models.

Smarter Decisions: Enhanced Pattern Matching

Pattern matching isn't new, but it's been steadily enhanced, making complex conditional logic incredibly readable and concise. It allows you to test an expression against various "patterns" and execute code based on a match.

`switch` Expressions and Property Patterns

Gone are the days of clunky switch statements with case and break. switch expressions are, well, expressions – they return a value, making them perfect for transformations. Combine that with property patterns, and you have some serious power.

// Imagine a DTO or some input object
public record OrderItem(string ItemType, int Quantity, decimal UnitPrice);

public decimal CalculateDiscount(OrderItem item) => item switch
{
    // If ItemType is "Book" AND Quantity > 5, apply 10% discount
    { ItemType: "Book", Quantity: > 5 } => item.Quantity * item.UnitPrice * 0.10M,
    // If ItemType is "Software" AND UnitPrice > 100, apply 5% discount
    { ItemType: "Software", UnitPrice: > 100 } => item.Quantity * item.UnitPrice * 0.05M,
    // Any other case
    _ => 0M
};

// Even simpler: type patterns
public string GetShapeInfo(object shape) => shape switch
{
    Circle c when c.Radius > 10 => $"Large Circle with radius {c.Radius}",
    Circle c => $"Small Circle with radius {c.Radius}",
    Rectangle r => $"Rectangle {r.Width}x{r.Height}",
    _ => "Unknown shape"
};

This syntax is incredibly powerful for expressing intent clearly. Instead of nested if/else if statements, you get a clean, declarative structure that's easy to read and maintain.

Wrapping Up

These are just a few of my personal highlights from the recent evolutions of C#. From making quick scripts easier with top-level statements to building robust, immutable data models with records, and writing more expressive conditional logic with pattern matching, C# continues to empower developers to write cleaner, more maintainable code.

It's a fantastic time to be a C# developer, and I'm always excited to see what's next!

What new C# feature has made the biggest difference in your daily coding life? Let me know in the comments!

Migration from .NET 4.7 to .NET 10

Mo — Sun, 07 Dec 2025 14:32:14 +0000

Travels in Time:

The Great Migration from .NET Framework 4.7 to .NET 10 🚀

All of us have encountered this situation: inheriting a project that has remained untouched for years, only to discover it is now outdated. Recently, I was assigned to such a project with a clear directive to modernise a legacy application built on .NET Framework 4.7 and successfully migrate it to the latest LTS release, .NET 10.

It was a journey filled with architectural archaeology, AI tooling, and some tough decisions. Here is the story of how we managed the upgrade of this legacy application using Visual Studio 2026, and what we learned along the way.

🧐 Phase 1: The Archaeology

My journey began with a classic induction meeting with my Line Manager and Product Owner. Once the pleasantries were done, I popped the hood to see how the project was structured.

As expected with legacy code, there wasn't much of a "structure" to speak of. It was a flat architecture where almost all business logic lived directly inside the Controllers. Even worse, database contexts were being instantiated right there in the controller methods, something like this:

public class LegacyController: Controller {
    public ActionResult Index() {
        // Direct instantiation inside the controller? Check.
        using (var db = new MyDbContext()) { ... }
    }
}

I knew that if I started refactoring immediately, I would generate a massive amount of changes that would be impossible to review properly, increasing the risk of failure.

The Initial Health Check

I decided to run the application to understand the flow without getting bogged down in the nitty-gritty of every single class. I also ran the existing unit tests. Unsurprisingly, red lights flashed everywhere.

The project lacked a proper CI/CD pipeline, so over time, business logic had drifted, while the tests had been forgotten.

📋 Phase 2: The Battle Plan

I went back to the Azure Board and tagged my Line Manager and PO with a plan. I proposed a strict order of operations to mitigate risk:

Stabilize: Pass all current unit tests to ensure the application works before we touch the framework.
Upgrade: Move the project directly from .NET Framework 4.7 to .NET 10.
Modernise: Once stable on .NET 10, implement a proper CI/CD pipeline in Azure DevOps.

I spent a few days fixing bugs in the test suite until everything was green. Only then was I ready for the big lift.

🛠 Phase 3: The Upgrade (Dependencies & AI Tools)

Using the newly released Visual Studio 2026, I started by auditing our NuGet packages and third-party references.

The Third-Party Challenge

One significant hurdle was a reference to Excel-DNA. When upgrading, checking vendor compatibility is non-negotiable. I had to comb through their documentation to find their specific upgrade process for .NET 10 compatibility.

The Entity Framework Dilemma

We were also using Entity Framework 6 (EF6). While EF6 is technically compatible with .NET 10, the long-term goal is obviously Entity Framework Core. However, trying to do that migration simultaneously would have blown up the scope. My manager and I agreed: get to .NET 10 first, upgrade to EF Core later.

AI vs. Legacy Tools

Visual Studio 2026 offers a tool called Modernizer, which leverages AI (ChatGPT, Gemini, Claude) to handle upgrades.

Tool	Verdict
Modernizer (AI)	Fantastic for simple class libraries. It proposed excellent upgrade plans and did the heavy lifting.
Legacy Upgrade Assistant	Necessary for the complex UI projects. The AI struggled with our old AngularJS/MVC mix, so I had to enable this legacy tool via `Tools > Options`.

🏗 Phase 4: Execution

Step 1: Low-Hanging Fruit

I started with the solution's four projects. Three were simple class libraries, so I used the Modernizer AI tool to upgrade them to .NET 10 first.

Pro Tip: When upgrading, resist the urge to use new features immediately. .NET 10 has cool toys like file-scoped namespaces, but mixing feature changes with framework upgrades creates noisy Pull Requests (PRs). I kept the code changes minimal so my team could actually review the PR.

Step 2: The Web Project (The Beast)

The main website was an ASP.NET MVC application with AngularJS. The Legacy Upgrade Assistant handled the C# conversion well, but it had no idea what to do with the UI.

The Bundling Problem:
Old ASP.NET had built-in bundling for CSS and JS. .NET 10 doesn't work that way. I had to:

Find npm equivalents for our NuGet client-side packages.
Implement a new build process.

I decided to use Gulp to compile our TypeScript and LESS files and bundle them. I utilised AI heavily to generate the Gulp tasks (which worked perfectly), creating a single output file referenced in our index.html.

Step 3: The Inevitable Refactor

Here is where I had to break my own rule about "minimal changes." The old code was so non-SOLID that I literally couldn't inject the services I needed into the controllers.

I had to refactor the presentation layer, introducing the Unit of Work pattern and cleaning up the dependency injection. It made the PR larger, but it was unavoidable to get the application running.

✅ Phase 5: Crossing the Finish Line

With the refactoring done, I ran the project. Miraculously (or perhaps due to the preparation), it worked.

I performed end-to-end testing, deployed to the test environment, and handed it over to QA. Everything looked green. I opened the PR, which was only "50% of the job" considering the future work needed, but the platform was now on .NET 10.

🔮 What's Next?

We successfully reached .NET 10, but the journey isn't over. We still need to upgrade to EF Core and add observability.

However, the business has shifted priorities. The old AngularJS frontend is now a security vulnerability. We aren't just upgrading to modern Angular; my manager wants a complete rewrite of the presentation layer using React.

There’s just one catch: I don't know React very well yet.

It’s going to be a challenging task, but I plan to tackle it head-on. Stay tuned, I’ll be sharing how I manage that learning curve in my next post.

Happy coding!

🚀 Event-Driven Architecture (EDA): The Power of Reacting to Events

Mo — Mon, 03 Nov 2025 07:48:16 +0000

Hey everyone 👋

Today, we’re diving into one of my favourite software architecture topics, Event-Driven Architecture (EDA). It’s one of those patterns that sounds a bit fancy at first, but once you understand it, you start seeing it everywhere: in cloud applications, microservices, and even your daily notifications!

Let’s break it down step by step. ☕

🧩 What Is Event-Driven Architecture?

At its core, Event-Driven Architecture is all about reacting to events.

An event is simply something that happened, for example:

An order was placed 🛒
A payment was completed 💳
A user logged in 👤

Instead of having tightly coupled services that directly call each other (as in layered or traditional microservice architectures), EDA uses events as the main form of communication.

Here’s where the magic happens ✨:
In EDA, each service acts independently. When something happens, a service simply publishes an event, it’s like saying:

“Hey, an order was placed!”

But here’s the cool bit: the service that emits the event doesn’t know (or care) who is listening, when they’ll react, or how they’ll process it.

That’s a big contrast to traditional architectures, where services often directly call one another through APIs.

EDA, on the other hand, is asynchronous and decoupled. Services communicate via an event broker (or message queue), meaning they’re completely independent; they just publish events into a queue without caring who processes them later.

💡 Why EDA Matters

This independence makes EDA:
✅ Highly scalable
✅ Fault-tolerant
✅ Easier to evolve over time

But it’s not always simple. While EDA offers powerful flexibility, it also introduces complexity. So before jumping in, we need to answer a few important questions 👇

🧠 Key Questions to Understand EDA

What’s the difference between an event and a message?
How do we ensure no data loss?
How many brokers or queues do we need?
How do we track state across multiple services?

Let’s explore each one.

🔁 Events vs. Messages

In EDA, the main concept is an event.

When an event is raised, we don’t care who processes it or when. The system just publishes the event, fire and forget. 🔥

Events: Fire and forget. The publisher emits and moves on.
Messages: Commands or queries, requests that expect a result.

So, in message-driven architecture, a message waits for a response, while in event-driven architecture, we publish and continue working asynchronously.

Most EDA systems use a Pub/Sub pattern, one service publishes events and others subscribe to them.
In contrast, message-driven systems usually use point-to-point communication since the sender knows exactly which service should handle the message.

🧱 Ensuring No Data Loss

One of the biggest challenges in EDA is data integrity.

Imagine this:

A service publishes an event to a queue, but right after that, the queue crashes, and the event is gone! 😱
Or maybe the consumer reads the event but fails before saving it to the database, and the data is lost again!

To prevent this, we can use the Event Forwarding Pattern 🛡️

Here’s how it helps:

Persist Events, Before a service sends an event to the queue, it first persists it in durable storage.
Recover Gracefully, If a service crashes after reading an event, it can re-fetch it later because the queue retained a persisted copy.
Track Consumers, Store client IDs so each service knows which messages it has processed.
Confirm Completion, After saving to the database, the service confirms success so the event can safely be removed from the queue.

This ensures strong data integrity ✅, but it comes with trade-offs:

Lower performance (because of synchronous writes)
Possible duplicate data

So, use this approach when data reliability is more important than throughput.

🏗️ How Many Brokers Do We Need?

Good question! Should each microservice have its own broker, or should they all share one?

Let’s look at the concept of Architectural Quantum, introduced in Building Evolutionary Architectures 🧠

An Architectural Quantum is an independently deployable component with high functional cohesion that includes everything needed for the system to work properly.

If all services depend on a single broker, then if that broker goes down, everything goes down.
This means the entire system is one single architectural quantum.

But if each service has its own broker, then you have multiple independent systems, more resilient, but also more expensive 💸.

A balanced approach is the Domain Broker Pattern:

Each domain gets one broker.
Services within a domain share the same broker.
Domains remain independent of one another.

This gives you a nice balance between cost and independence.

🔍 Managing State in EDA

Tracking the state of an entity (like an order) across distributed services can be tricky. Let’s say you have:

An Order Service 🛒
An Inventory Service 📦
A Delivery Service 🚚

When a user asks, “What’s the status of my order?”, where should we look?

There are two main patterns for managing state:

1️⃣ Push-Based Pattern

Each service writes status updates to a shared queue.
The Order Service listens to this queue and keeps the latest status in its database.

✅ Pros:

Centralized status tracking
Easy to query

⚠️ Cons:

All services depend on one queue → Architectural quantum = 1
A single failure can bring down the whole system

2️⃣ Pull-Based Pattern

In this model, a separate Status Service listens to events from all brokers.
It collects and stores the latest status for each order.

✅ Pros:

No shared dependency, more resilient
Central point for querying order status

⚠️ Cons:

Requires building and maintaining an extra service

🏁 Final Thoughts

Event-Driven Architecture is incredibly powerful; it enables scalable, resilient, and decoupled systems. But like any architecture, it’s not a one-size-fits-all solution.

EDA shines when:

You have many independent services that react to real-time changes
You need asynchronous communication
You care more about flexibility and responsiveness than strict performance

However, it adds complexity in state management, data integrity, and broker design, so plan carefully before adopting it.

Thanks for reading! 🙌
If you found this useful, don’t forget to share it with your fellow developers and let’s keep learning together 💬

Proper Logging in ASP.NET Core

Mo — Wed, 19 Mar 2025 06:49:53 +0000

Hey there, fellow code warriors! 👋 Today, we're diving deep into proper logging in ASP.NET Core. If you've ever found yourself lost in a sea of mysterious bugs or scratching your head over your application's behaviour, this guide is your lighthouse! 🏝️

Why Logging Matters 🤔

Before we jump into the code, let's talk about why logging is the unsung hero of software development. Proper logging is like giving your future self (and your team) a roadmap to understand what's happening in your application. It's not just about catching errors; it's about gaining insights, improving performance, and making your development life easier.

Here's why logging is crucial for your projects:

Application Behavior Monitoring: It's like having a 24/7 surveillance camera on your code.
Event Capturing: Every important moment in your app's life, documented.
Performance Insights: Because sometimes, your app needs a health check.

But logging isn't just about writing stuff down. It's part of a trio of concepts that make your applications robust, maintainable, and scalable:

The Holy Trinity of Application Observability 🛠️

Logging: Your app's diary 📔
- Records events, errors, and important information
- Helps debug issues quickly
- Provides insights into application behaviour
Traceability: Following the breadcrumbs of your code 🍞
- Tracks the flow of application processes
- Follows the lifecycle of requests or commands
- Especially helpful for distributed systems or microservices
- Facilitates debugging and enhances reliability
Metrics: Measuring what matters 📊
- Provides measurable data about application performance
- Helps make data-driven decisions
- Enhances user experiences through targeted optimizations

Implementing Logging with Serilog in ASP.NET Core 🛠️

Let's roll up our sleeves and get our hands dirty with some code! We'll be using Serilog, a powerful logging library for .NET.

Setting Up Serilog

First, add the Serilog.AspNetCore NuGet package to your project. If you're planning to use Azure Application Insights, grab Serilog.Sinks.AzureApp too.

In your Program.cs, set up Serilog like this:

builder.Logging.ClearProviders();
builder.Host.UseSerilog(((context, configuration) => 
    configuration.ReadFrom.Configuration(context.Configuration)));

This code clears any existing logging providers and tells Serilog to read its configuration from the appsettings.json file.

Configuring Serilog

In your appsettings.json, you can configure Serilog like a boss:

{
    "Serilog": {
    "Using": [
      "Serilog.Sinks.Console",
      "Serilog.Sinks.File"
    ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "Console",
        "Args": {
          "theme": "Serilog.Sinks.SystemConsole.Themes.AnsiConsoleTheme::Code, Serilog.Sinks.Console",
          "outputTemplate": "[{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}"
        }
      },
      {
        "Name": "File",
        "Args": {
          "path": "Logs/log-.txt",
          "rollingInterval": "Day",
          "rollOnFileSizeLimit": true,
          "outputTemplate": "[{Timestamp:yyyy-MM-dd HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}",
          "fileSizeLimitBytes": 1073741824
        }
      },
      {
        "Name": "AzureApp",
        "Args": {
          "instrumentationKey": "your_instrumentation_key"
        }
      }
    ],
    "Enrich": [
      "FromLogContext",
      "WithMachineName",
      "WithThreadId"
    ]
  }
}

This configuration sets up Serilog to:

Use both console and file sinks
Set default log levels (Information for production, Debug for development)
Write logs to the console and a file
Send logs to Azure Application Insights

Logging in Action: GlobalExceptionHandler 🎭

Our GlobalExceptionHandler class is like a superhero for exceptions. It catches them, logs them, and sends back a nicely formatted response to the user.

public async ValueTask TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
{
    // ... (exception handling logic)

    _logger.LogError(exception, "An error occurred while processing the request {DateTime} {Path}", 
        DateTime.UtcNow, httpContext.Request.Path);

    // ... (return problem details)
}

This class inherits from IExceptionHandler and is registered in our dependency injection setup. It formats errors based on their type and logs them in a structured way before returning a user-friendly response.

Request Logging with LoggingBehaviour 🕵️

The LoggingBehaviour class is our secret agent, tracking every request that passes through our application.

public async Task Handle(TRequest request, RequestHandlerDelegate next, CancellationToken cancellationToken)
{
    Stopwatch stopWatch = Stopwatch.StartNew();
    logger.LogInformation("Handling request {Name}, {DateTime} ", request.GetType().Name, DateTime.UtcNow);

    // ... (request handling)

    if (stopWatch.ElapsedMilliseconds > SlowRequestThresholdMilliseconds)
    {
        logger.LogWarning("Request took too long to handle {Name}, {DateTime}, {ElapsedMilliseconds}ms", 
            request.GetType().Name, DateTime.UtcNow, stopWatch.ElapsedMilliseconds);
    }

    if (result.IsSuccess)
    {
        logger.LogInformation("Request handled successfully {Name}, {DateTime}", request.GetType().Name, DateTime.UtcNow);
    }
    else
    {
        logger.LogError("Request failed to handle {Name}, {DateTime}, {@Error}", request.GetType().Name, DateTime.UtcNow, result.Errors);
    }

    // ... (log success or failure)
}

This class implements IPipelineBehavior from the MediatR library, acting as a pipeline for each request. It measures request duration, logs warnings for slow requests, and records the outcome of each request.

Pro Tips for Logging Like a Boss 😎

Use Structured Logging: Always include relevant context in your logs. Serilog makes this easy with templates.
Log Levels Matter: Use the right log level for the right situation. Not everything is an error!
Performance Matters: Logging can impact performance, so use it wisely.
Sensitive Data Alert: Be careful not to log sensitive information. Your logs shouldn't be a security risk!
Use the "@" Symbol: When logging objects with Serilog, use the "@" symbol (e.g., {@Error}) to serialize the entire object. This makes querying logs easier, especially with tools like Seq.

Wrapping Up 🎁

Proper logging is an essential skill for any developer working with ASP.NET Core. It's not just about catching errors; it's about gaining insights, improving performance, and making your development life easier.

Remember, your logs are your best friend when things go wrong (and even when they don't). They're your application's black box, recording every important event and helping you understand what's happening under the hood.

So, the next time you're debugging a tricky issue or trying to understand why your app is behaving weirdly, remember: that your logs are there to help. Happy logging, developers! 🚀

The source code is available in my Github repo.

JWT Authentication & Authorization in ASP.NET

Mo — Tue, 04 Mar 2025 18:06:31 +0000

Hey everyone, welcome to our deep dive into JWTs in ASP.NET Core! Whether you’re a beginner or a seasoned developer, this article will guide you through the ins and outs of implementing secure authentication and authorization using JSON Web Tokens (JWT). Grab your favourite beverage, sit back, and let’s get started! 😊

What is JWT? 🔍

JWT stands for JSON Web Token. Think of it as a digital passport that securely transmits information between parties. It’s compact, URL-safe, and self-contained, meaning all the necessary data for authentication is right inside the token. A JWT consists of three key parts:

Header:

Specifies the token type and the hashing algorithm used (e.g., HMAC SHA256).
Payload:

Contains the claims—statements about an entity (usually the user) such as their ID, email, and roles. These claims are essential for both authentication and authorization.
Signature:

Ensures that the token hasn’t been tampered with. It’s created using the header, payload, and a secret key.

You can explore JWTs and see their inner workings at jwt.io 🔗.

How Does the Authentication & Authorization Process Work? 🛡️

When a client sends a request to a secure API, here’s what happens behind the scenes:

Client Request:

The client sends a request including the JWT in the Authorization header.
Authentication:
- The ASP.NET authentication provider extracts the JWT.
- It validates the token’s signature, expiration, and issuer.
- If valid, the user is authenticated.
Authorization:
- The server checks if the user has the required claims to access the resource.
- If the claims match the required policy, access is granted; otherwise, a 403 Forbidden error is returned.

Policy-Based vs. Role-Based Access Control 🔐

Role-Based Access Control (RBAC)

RBAC assigns roles directly to users.
For example, only users with an Admin role might access certain endpoints.
This method can become unwieldy as your user base grows.

Policy-Based Access Control

Policy-Based access control defines policies (like CanRead) that are assigned to roles.
When a user’s role changes, their permissions update automatically without modifying each user individually.
This approach is more flexible and scalable, especially for larger applications.

In our demo, we focus on policy-based access control for that extra bit of flexibility!

Implementing JWT in ASP.NET Core: A Step-by-Step Guide 💻

Let’s walk through how to set up JWT authentication in an ASP.NET Core application.

Clone the project

Clone the project from Github and take a look at the authentication and authorisation configuration in the DependencyInjection.cs file:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer();
        services.AddAuthorization();
        services.AddSingleton<IAuthorizationHandler, PermissionAuthorizationHandler>();
        services.AddSingleton<IAuthorizationPolicyProvider, PermissionAuthorizationPolicyProvider>();

We have all authentication configuration in the JwtBearerOptionsSetup file:

internal class JwtBearerOptionsSetup(IOptions<JwtOptions> jwtOptions): IPostConfigureOptions<JwtBearerOptions>
{
    private readonly JwtOptions _jwtOptions = jwtOptions.Value;

    public void PostConfigure(string? name, JwtBearerOptions options)
    {
        options.RequireHttpsMetadata = false;
        options.SaveToken = true;
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = _jwtOptions.Issuer,
            ValidateAudience = true,
            ValidAudience = _jwtOptions.Audience,
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_jwtOptions.SecretKey)),
            ValidateLifetime = true,
            ClockSkew = TimeSpan.Zero
        };
    }
}

This setup ensures that every token is validated against your issuer, audience, and signing key.

To add permission authorisation, we have added two files PermissionAuthorizationHandler and PermissionAuthorizationPolicyProvider.

In the PermissionAuthorizationHandler we make sure that the request has enough permission:

public class PermissionAuthorizationHandler : AuthorizationHandler<PermissionRequirement>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, PermissionRequirement requirement)
    {
        HashSet<string> permissions = context
            .User
            .Claims
            .Where(x => x.Type == Constants.Claims.Permissions)
            .Select(x => x.Value)
            .ToHashSet();

        if (permissions.Contains(requirement.Permission))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }
}

Now, only requests with a valid JWT will be able to access these endpoints.

Another important file is JwtProvider which is responsible for creating the JWT token:

public sealed class JwtProvider(IOptions<JwtOptions> jwtOptions, IPermissionService permissionService) : IJwtProvider
{
    private readonly JwtOptions _jwtOptions = jwtOptions.Value;

    public async Task<string> GenerateJwtTokenAsync(User user)
    {
        List<Claim> claims =
        [
            new(JwtRegisteredClaimNames.Sub, user.Id.ToString()),
            new(JwtRegisteredClaimNames.Email, user.Email!),
            new(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString())
        ];

        HashSet<string> permissions = await permissionService.GetPermissionsAsync(user.Id);

        claims.AddRange(permissions.Select(permission => new Claim(Constants.Claims.Permissions, permission)));

        SigningCredentials signingCredentials =
            new(new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_jwtOptions.SecretKey)), SecurityAlgorithms.HmacSha256);

        JwtSecurityToken token = new(_jwtOptions.Issuer, _jwtOptions.Audience, claims,
            expires: DateTime.UtcNow.AddMinutes(_jwtOptions.TimeoutMinutes), signingCredentials: signingCredentials);

        return new JwtSecurityTokenHandler().WriteToken(token);
    }
}

That's all the configuration we need to know about JWT authentication and authorisation.

Wrap-Up & Key Takeaways 📝

Today, we explored:

JWT Fundamentals:

Understanding JWT as a secure, compact way to transfer claims between parties.
Authentication & Authorization Flow:

From initial user login to token validation and access control.
Policy-Based Access Control:

Offering flexibility over traditional role-based approaches by defining policies like CanRead that are associated with roles.
Implementation in ASP.NET Core:

A step-by-step guide including configuration, creating a login endpoint, and securing your APIs with JWT.

Implementing JWT in your ASP.NET Core applications not only simplifies authentication but also scales beautifully with your growing user base. If you have any questions or feedback, feel free to drop a comment below!

Happy coding! 💻✨

🚀Clean Architecture in .NET

Mo — Tue, 11 Feb 2025 15:51:35 +0000

Introduction

Hello, fellow developers! 👋 Hope you’re doing well.

In the world of software architecture, structuring our code properly is crucial for maintainability, scalability, and testability. In our last discussion, we explored different architectural patterns, including Hexagonal Architecture, Layered Architecture, Onion Architecture, and Clean Architecture.

Today, we’re going to dive deep into Clean Architecture, what it is, why it matters, and how we can implement it in a real-world .NET application. 💡

The full source code is available on GitHub, so feel free to download it and follow along! 🛠️

What is Clean Architecture? 🤔

Clean Architecture, introduced by Uncle Bob (Robert C. Martin), is a domain-centric approach that helps us build software that is:

✅ Flexible – Easy to swap technologies (databases, frameworks, UI).

✅ Maintainable – Well-structured code with minimal dependencies.

✅ Testable – Business logic remains independent of external concerns.

Layer Breakdown 🏗️

Clean Architecture is structured into four key layers:

1️⃣ Domain Layer (Core Business Logic) – Contains entities, value objects, and domain services.

2️⃣ Application Layer (Use Cases & CQRS) – Defines business rules, CQRS commands/queries, and interfaces.

3️⃣ Infrastructure Layer (Implementations & DB Access) – Implements interfaces from the Application Layer.

4️⃣ Presentation Layer (API/UI Controllers) – Exposes the functionality via endpoints or UI.

At its core, Clean Architecture follows the Dependency Rule:

Inner layers should not depend on outer layers.

This means that business logic is independent of frameworks, databases, and UI technologies. 🚀

Implementing Clean Architecture in .NET 🏗️

Let’s break down how we’ve structured a .NET application using Clean Architecture principles.

1️⃣ Domain Layer – The Heart of Clean Architecture

The Domain Layer is the most important part of Clean Architecture. It contains:

✅ Entities (Book, Person) – Define core data structures.

✅ Value Objects (Genre, Address) – Immutable objects with validation.

✅ BaseEntity & BaseAuditableEntity – Common properties like Id, CreatedDate, UpdatedDate.

✅ Domain Exceptions (UnsupportedGenreException) – Custom exceptions for domain-level errors.

✅ Domain Events – Handling important business events.

A key decision here:

📌 Using DateTimeOffset instead of DateTime ensures proper time zone handling across different regions.

👉 The Domain Layer has no dependencies on external frameworks or databases, keeping it pure and reusable.

2️⃣ Application Layer – Business Logic & CQRS

The Application Layer is where we define use cases and business rules. It consists of:

✅ CQRS (Command Query Responsibility Segregation) – Separating read and write operations.

✅ Interfaces (e.g., IEmailService) – Abstractions for external dependencies.

✅ Command Handlers (CreateBookCommandHandler, DeleteBookCommandHandler).

✅ Validation Rules – Using FluentValidation to enforce constraints.

✅ Unit of Work Pattern – Ensuring atomic transactions.

📌 Key concept:

Commands modify data (CreateBookCommand, UpdateBookCommand).
Queries retrieve data (GetBookByIdQuery).
The Application Layer only contains interfaces, keeping it decoupled from the infrastructure.

3️⃣ Infrastructure Layer – Implementation Details

The Infrastructure Layer provides concrete implementations of the interfaces defined in the Application Layer. It includes:

✅ Entity Framework Core (EF Core) Configuration – Setting up database persistence.

✅ ApplicationDbContext – The actual database context.

✅ Unit of Work Implementation – Managing transactions efficiently.

✅ Email Service Implementation – Sending emails using external services.

✅ Global Exception Handling – Standardizing error responses.

📌 Infrastructure should depend on Application, not the other way around. This keeps the core logic flexible while allowing technology choices to change without affecting the domain.

4️⃣ Presentation Layer – Exposing APIs & Dependency Injection

The Presentation Layer (CleanArchitecture.API) is the entry point of the application, responsible for:

✅ API Controllers – Handling requests and responses.

✅ Swagger Documentation – Interactive API documentation.

✅ Dependency Injection (DI) Setup – Registering services.

✅ Global Exception Handling – Formatting errors consistently.

📌 In Program.cs, we wire everything together:

builder.Services.AddApplicationServices();  
builder.Services.AddInfrastructureServices();  
builder.Services.AddPresentationServices();

This ensures all dependencies are properly injected across the application.

Key Benefits of Clean Architecture 🏆

✅ Separation of Concerns – Code is modular and easier to maintain.

✅ Scalability – Easily swap out technologies without major refactoring.

✅ Testability – Business logic remains independent and can be tested in isolation.

✅ Flexibility – The application can evolve over time with minimal disruption.

By following this structure, we ensure our .NET applications are robust, maintainable, and scalable. 🚀

Wrapping Up & Next Steps

That’s a complete walkthrough of Clean Architecture in .NET! 🎉

💡 What’s Next?

🔥 Download the source code from my GitHub repo and try it yourself!
👍 If you found this helpful, give it a star on GitHub!
📢 Have questions? Drop a comment below!
🔔 Subscribe for more .NET & Software Architecture content!

Thanks for reading, and happy coding! 🎯

Blue-Green Deployment with Azure

Mo — Wed, 22 Jan 2025 07:16:54 +0000

Hello, everyone! In this article, we’re diving into Blue-Green Deployment, a brilliant technique for rolling out updates without breaking a sweat—or your app.

Here’s what we’ll cover:

What is Blue-Green Deployment?
The Pros and Cons—because no approach is perfect.
When Should You Use It?
Step-by-Step Demo with Azure—complete with automation tips to make your life easier.

So, grab a cuppa ☕ and let’s get started! 🚀

What is Blue-Green Deployment? 🤔

Imagine you’ve got two versions of your application running—one is "Blue" (your live environment), and the other is "Green" (your shiny new version).

Instead of directly updating the live version and risking downtime, you deploy changes to the Green environment first. Once you’re sure everything’s working perfectly, you simply swap traffic from Blue to Green. Users won’t notice a thing—except the new features! 🎉

Think of it like swapping stage sets in a play between scenes—seamless and smooth. 🎭

The Pros and Cons 🛠️

Pros:

Zero Downtime: No 'under maintenance' messages—just uninterrupted service.
Easy Rollbacks: Found a bug? Flip back to Blue and fix it.
Production-like Testing: Test your new version in a real-world environment.
Better User Experience: Smooth updates = happy users.

Cons:

Higher Costs: You’re running two environments, which can double infrastructure costs.
Complex Setup: Managing two environments isn’t simple—it requires planning and good tools.
Data Synchronisation: Handling databases and real-time data can get tricky.
Testing Overheads: Blue and Green must be identical apart from the new features.

When Should You Use It? 🎯

Blue-Green Deployment shines when downtime isn’t an option—think e-commerce sites, banking systems, or services that need constant availability.

If you’re working on a smaller project or have a tight budget, the added complexity and cost might not be worth it.

Demo with Azure 🖥️

Let’s put theory into practice! I’ll guide you through setting up Blue-Green Deployment using Azure.

Step 1: Create a Web App 🌐

Set up a resource group called BlueGreenResource.
Create a web app named BlueGreenWebApp. Use .NET 8, deploy to UK South, and choose the Standard S1 pricing tier.
Disable App Insights (optional for simple setups).

Step 2: Publish the First Version ✅

Use Visual Studio to deploy your app to the live environment.
This is version 1, which users can now see. 🎉

Step 3: Add a Staging Slot 🛠️

Add a staging slot to your web app. It’ll have its own domain (e.g., staging.bluegreenwebapp.azurewebsites.net).
Publish version 2 to this staging slot. Users won’t see this version yet, but it’s ready for testing.

Step 4: Swap the Slots 🔄

Once QA approves, use the Swap button in Azure to swap the staging slot with the live slot. Now, users are on version 2! 🎊

Step 5: Clean Up 🧹

Delete the staging slot to save costs.

Automate the Process with Azure DevOps 🤖

To avoid manual effort, we’ll set up a CI/CD pipeline in Azure DevOps:

Build Pipeline (YAML File):

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'deploymentapp-artifact'

This pipeline triggers on changes to the master branch. It builds the app, restores NuGet packages, and creates deployment artifacts.

Release Pipeline:

Create a Staging Slot: Use this script:

   az webapp deployment slot create --name $(webAppName) --resource-group $(resourceGroupName) --slot $(slotName)

Deploy to Staging:

Set the staging slot as the target in the pipeline.
Swap Slots:

Use the Azure App Service Manage task to swap environments.
Delete Staging Slot:

Clean up with this script:

   az webapp deployment slot delete --name $(webAppName) --resource-group $(resourceGroupName) --slot $(slotName)

Testing the Setup 🚀

Push changes to the master branch, and watch the magic happen:

Build triggers automatically.
Deployment to the staging slot occurs.
QA approves the changes.
Slots are swapped, and the staging slot is deleted.

Final Thoughts 💡

Blue-Green Deployment makes updates safer, faster, and smoother, especially for critical systems. While it’s not without challenges, automation tools like Azure DevOps make it easier to manage.

Have you tried Blue-Green Deployment? Share your experiences in the comments! 👇 Don’t forget to like, share, and bookmark this article for future reference. 😊

Generic Class & Constraints in C#

Mo — Sun, 05 Jan 2025 13:36:58 +0000

Generics are one of the most powerful tools in C#, enabling reusable, type-safe, and flexible code. But with great power comes great responsibility, and that’s where constraints on generics come into play. In this article, we’ll dive deep into generic constraints in C#, starting from the basics and progressing to advanced use cases.

Why Do We Need Generics?

Let’s first understand why generics exist. Imagine you’re writing a class to process integers and strings. Without generics, you’d need to write separate methods or overloads for each type:

public class Processor
{
    public void Process(int number)
    {
        Console.WriteLine($"Processing integer: {number}");
    }

    public void Process(string text)
    {
        Console.WriteLine($"Processing string: {text}");
    }
}

While this works, it quickly becomes unmanageable if you need to handle multiple types like float, bool, or custom objects. The code becomes verbose, error-prone, and harder to maintain.

Enter Generics

Generics solves this problem by allowing you to write a single class or method that works with any type. Here’s how the same Processor class looks with generics:

public class Processor<T>
{
    public void Process(T item)
    {
        Console.WriteLine($"Processing: {item}");
    }
}

// Usage:
var intProcessor = new Processor<int>();
intProcessor.Process(42);

var stringProcessor = new Processor<string>();
stringProcessor.Process("Hello, world!");

With generics, the Processor class works with any type, eliminating redundancy and ensuring type safety.

Class-Level vs Method-Level Generics

When working with generics, you can define them at the class level or method level.

Class-Level Generics: Use when the type parameter applies to the entire class.
Method-Level Generics: Use when you need type flexibility for only a specific method.

Here’s an example of both:

// Class-level generic
public class Storage<T>
{
    private List<T> _items = new List<T>();

    public void Add(T item)
    {
        _items.Add(item);
        Console.WriteLine($"{item} added to storage.");
    }
}

// Method-level generic
public class Utility
{
    public void Print<T>(T item)
    {
        Console.WriteLine($"Printing: {item}");
    }
}

// Usage:
var storage = new Storage<string>();
storage.Add("Hello, storage!");

var utility = new Utility();
utility.Print(42);

Understanding Generic Constraints

While generics are flexible, sometimes you need to restrict what types can be used. Constraints allow you to enforce specific requirements, such as the type being a value type, a reference type, or implementing an interface.

Let’s explore the various constraints and their usage.

1. Value Type Constraint (`struct`)

The struct constraint ensures that the type parameter is a value type, such as int, float, or a custom struct.

public class ValueProcessor<T> where T : struct
{
    public void ProcessValue(T value)
    {
        Console.WriteLine($"Processing value: {value}");
    }
}

// Usage:
var intProcessor = new ValueProcessor<int>();
intProcessor.ProcessValue(100);

var floatProcessor = new ValueProcessor<float>();
floatProcessor.ProcessValue(99.99f);

This is perfect for scenarios where you’re working with numeric types, enums, or other non-nullable structures.

2. Reference Type Constraint (`class`)

The class constraint ensures that the type parameter is a reference type, such as string or a custom object.

public class ReferenceProcessor<T> where T : class
{
    public void ProcessReference(T reference)
    {
        Console.WriteLine($"Processing reference: {reference}");
    }
}

// Usage:
var stringProcessor = new ReferenceProcessor<string>();
stringProcessor.ProcessReference("Hello, Reference!");

var objectProcessor = new ReferenceProcessor<object>();
objectProcessor.ProcessReference(new { Name = "C#", Version = 12 });

This is ideal for working with objects that support nullability.

3. Nullable Types

If you want to allow nullable value types, you can use a nullable type in your constraint.

public class NullableProcessor<T> where T : struct
{
    public void ProcessNullable(T? value)
    {
        Console.WriteLine($"Processing nullable value: {value}");
    }
}

// Usage:
var nullableIntProcessor = new NullableProcessor<int>();
nullableIntProcessor.ProcessNullable(null);
nullableIntProcessor.ProcessNullable(42);

This is great for handling scenarios like optional parameters or database fields that may contain null values.

4. Constructor Constraint (`new()`)

The new() constraint ensures that the type parameter has a parameterless constructor, allowing you to create new instances.

public class InstanceCreator<T> where T : new()
{
    public T CreateInstance()
    {
        return new T();
    }
}

// Usage:
var creator = new InstanceCreator<StringBuilder>();
var instance = creator.CreateInstance();
instance.Append("Hello from InstanceCreator!");
Console.WriteLine(instance.ToString());

This is especially useful when you need to instantiate objects dynamically.

5. Interface and Multiple Constraints

You can combine multiple constraints to enforce stricter rules.

public interface IEntity
{
    int Id { get; }
}

public class Repository<T> where T : class, IEntity, new()
{
    private readonly List<T> _items = new List<T>();

    public void Add(T item)
    {
        _items.Add(item);
        Console.WriteLine($"Added entity with ID: {item.Id}");
    }
}

// Usage:
public class Product: IEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
}

var repository = new Repository<Product>();
repository.Add(new Product { Id = 1, Name = "Laptop" });

Here, T must:

Be a reference type (class).
Implement the IEntity interface.
Have a parameterless constructor (new()).

This combination provides structure and consistency for your types.

Conclusion

Generics and their constraints are indispensable tools for writing reusable, type-safe, and maintainable code in C#. Whether you’re enforcing type safety or structuring your code better, constraints help you achieve flexibility without sacrificing reliability.

Take some time to experiment with these constraints in your projects, and see how they can simplify your codebase!

What’s your favourite use case for generics? Let me know in the comments!

Evolution of Software Architecture

Mo — Sat, 07 Dec 2024 13:14:02 +0000

🌐 Exploring the Evolution of Software Architecture

Hello everyone! 👋 Welcome back to the channel where we dive into the world of software development, one fascinating concept at a time. Today, we're embarking on a journey through the evolution of software architecture—from the foundational Layered Architecture, through Hexagonal and Onion Architecture, all the way to the increasingly popular Clean Architecture.

Have you ever wondered:

How did these architectural patterns come to be?
Why do some designs suit certain applications better than others?

As Jamie, my colleague, says: "It depends—no one architecture fits all."

By the end of this article, you'll have a clear understanding of these styles, their historical progression, key principles, and practical applications. Whether you're new to software architecture or a seasoned developer looking for a refresher, this one's for you! 🎉

🏗️ Layered Architecture: The Starting Point

The Layered Architecture (a.k.a. N-tier architecture) breaks a system into distinct layers like:

Presentation Layer
Business Logic Layer (BLL)
Data Access Layer (DAL)

Key Features:

Simplicity: Easy to understand, implement, and use.
Structure: The Presentation Layer depends on the BLL, which in turn depends on the DAL.

However, this creates tight coupling between layers, making the system rigid and hard to scale. Architects have since evolved designs to address these limitations.

🔧 Making Business Logic the Focal Point

To improve the architecture:

Shift dependency to the business logic layer.
Introduce interfaces like:
- IRepository in the core, with its implementation in the DAL.
- IEmailService to abstract email communication systems.

This strategy gives rise to Hexagonal Architecture, enhancing modularity and flexibility.

🔷 Hexagonal Architecture: Breaking Free from Coupling

Also called the Ports and Adapters pattern, Hexagonal Architecture emphasises business logic as the core of the system.

Visualising the Structure:

Primary (Driving) Adapters: User interfaces like CLI or APIs.
Secondary (Driven) Adapters: External systems like databases or email services.
Core Application: Processes requests and directs flows.

The system interacts with external dependencies via ports (interfaces) and adapters (implementations), enabling a loosely coupled design.

🌀 Onion Architecture: A Step Further

Building on hexagonal principles, Onion Architecture arranges systems into concentric circles:

Domain Models and Business Rules: At the centre.
Application Services and Infrastructure: Surrounding layers.

Core Principles:

Dependency Inversion: Outer layers depend on inner layers.
Flexibility: Changes to UI or external systems don't affect business logic.

This design supports testability and aligns well with Agile development practices. 🎯

🌟 Clean Architecture: The Best of All Worlds

Clean Architecture simplifies earlier patterns while retaining their strengths.

Highlights:

Business Rules at the Centre: The domain layer handles all core logic.
Focus on Use Cases: Emphasises what the system does rather than how it achieves it.

For example:

Multiple implementations for IEmail can exist, but the Web UI layer decides which to use dynamically.
Independence from frameworks makes systems more maintainable and adaptable.

🛠️ From Hexagonal to Clean Architecture

The journey from Hexagonal to Clean Architecture focuses on:

Making the application core resilient to changes.
Enhancing maintainability by layering the core logically.

🎯 Summary of the Journey

Layered Architecture: Introduced clear separations but had tight coupling.
Hexagonal Architecture: Decoupled business logic via ports and adapters.
Onion Architecture: Emphasised domain models with dependency inversion.
Clean Architecture: Focused on simplicity, use cases, and maintainability.

Each pattern represents a step forward in designing robust, scalable, and adaptable systems. 💡

That wraps up our deep dive into software architecture! From foundational layers to the elegance of Clean Architecture, we've traced how these patterns evolved and adapted over time. Hopefully, you've gained insights to inspire your next project.

If you enjoyed this, please:

👍 Like

📢 Share

💬 Comment below!

Thanks for reading, and I'll see you in the next one. Cheers! ☕

Fundamentals of Software Architecture

Mo — Sat, 19 Oct 2024 08:15:07 +0000

Hey everyone! 👋 Welcome back to the channel! If you’re new here, hit that like button so you don’t miss out on any of our upcoming content. Today we’re diving into the fundamentals of software architecture, an incredibly important topic for developers and tech enthusiasts alike. By the end of this video, you'll have a solid understanding of what software architecture is and why it’s crucial for building scalable and reliable software systems.

We'll also cover the differences between architecture patterns and architecture styles, two terms that often confuse people but are key to designing great systems.

So let's jump right in!" 🚀

What Is Software Architecture?

So let’s start with the basics: what exactly is software architecture? In simple terms, software architecture is all about making critical decisions on how your system is structured and functions, while keeping the business's needs in mind. At its core, architecture is about the important stuff. It’s the foundation that holds the entire system together.

What’s a great architecture for one project might be totally wrong for another because business requirements vary. For example, if the business needs to handle massive user loads quickly, your architecture should be designed with performance in mind. But if cost is a higher priority, you may need to design with efficiency and cost-saving strategies.

In short, there isn’t a single correct architecture for every scenario—it’s all about tailoring your system to meet the specific goals of the business! 🏗️

Who is a Software Architect?

Now who exactly is a software architect? It sounds a bit mysterious, doesn’t it? Some might think architects are mythical beings who know everything about every technology out there! 🧙‍♂️ Well, not quite! A software architect bridges the gap between the technical and business sides of things.

Software architects need a mix of technical and soft skills. They’re familiar with various architecture styles, frameworks, and anti-patterns but also need to be excellent communicators. Architects work closely with developers, stakeholders, and sometimes clients to ensure everyone is aligned on the system’s goals.

And here’s the thing—becoming a software architect isn’t always a straightforward path. It’s a journey filled with experience, learning, and a deep understanding of solving complex problems. 🎯

The Four Pillars of Software Architecture

Let’s talk about the four key pillars of software architecture:

Structure or Style
Architecture Characteristics
Architecture Decisions
Design Principles
Structure or Style: How is your system organized? Are you building a monolithic system, or are you using microservices? Maybe an event-driven approach is best. Each style affects how your system functions and scales.
Architecture Characteristics: These are the non-negotiables—your functional and non-functional requirements. Do you need high availability? What about scalability or performance? These characteristics shape your architectural decisions.
Architecture Decisions: These are the high-level rules you set. For instance, you might decide that only the business logic layer interacts with the database directly. 🗂️ Decisions like this help maintain structure and consistency.
Design Principles: This is where implementation happens! What technologies will you use? Maybe you'll opt for CQRS, Clean Architecture, or asynchronous programming. 💡

Architecture Pattern vs. Architecture Style

Let’s clear up a common confusion: What’s the difference between an architecture pattern and an architecture style? 🤔

Architecture Pattern: A solution to a specific problem. For example, the CQRS (Command Query Responsibility Segregation) pattern helps separate write and read operations, making your system more efficient for certain scenarios.
Architecture Style: This is the overall structure of your system. Are you designing with microservices, a layered architecture, or something else entirely? Your choice here dictates how the system is organized, but not how individual problems are solved. 🏗️

Summary

We’ve only scratched the surface of software architecture today. Next time, we’ll dive deeper into patterns like Clean Architecture and explore the benefits of asynchronous programming.

If you enjoyed the content, don’t forget to subscribe and hit the notification bell so you won’t miss out. Until next time, take care and happy coding! 💻

Software Architecture: A Journey Through Time 🕰️

Mo — Fri, 04 Oct 2024 05:39:52 +0000

Hello everyone! Hope you're all doing well! 😊 In today’s post, we’re diving into the fascinating world of Software Architecture. We'll journey through its history, explore the differences between architecture and design, and clarify the often-confused terms software architecture and software design. So, let’s get started!

A Brief History of Software Architecture 🏛️

To truly appreciate software architecture as we know it today, we need to rewind the clock and explore how it evolved:

1950s: The early days of computing, where coding was mostly low-level and done in assembly languages. The concept of "architecture" didn't exist yet.
1960s: The rise of structured programming and the birth of object-oriented programming (OOP), marking the first steps towards modularity and component-based design. A small step for programming, but a giant leap for architecture! 🚀
Late 1960s: Enter monolithic architectures—systems where everything was built as one large unit. People started theorising about how to structure software, laying the groundwork for more sophisticated architectures.
1970s: Big innovations like microkernel architecture came along. This modular design had a core system (the microkernel) surrounded by components. Plus, event-driven programming made it possible for systems to respond to events, creating a more dynamic interaction between modules.
1978: The rise of Client-Server architecture. Initially, servers handled everything, but soon the Model-View-Controller (MVC) pattern was introduced to divide responsibilities more efficiently.
1980s & 1990s: More refined architectures came into play like Command-Query Separation (CQS). This was also the era when the web browser was born! 🌐 With the rise of the internet, architectures like Service-Oriented Architecture (SOA) and Domain-Driven Design (DDD) emerged.
2000s: The modern age of Microservices, Onion Architecture, CQRS (Command Query Responsibility Segregation), and Clean Architecture. These patterns are designed for scalability, maintainability, and modularity.

Architecture vs Design 🏗️🛠️

Let’s clear up a common point of confusion: what's the difference between software architecture and software design? 🤔

Architecture: The Big Picture

Think of architecture as the blueprint of your system. It defines the structure, how components interact, and the guiding principles like scalability and modularity.

For example, in C#, you might decide that your system will follow a Microservices architecture to ensure modularity and ease of scaling. Here’s how you might define a service in C#:

public class UserService
{
    private readonly IUserRepository _userRepository;

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

    public async Task<User> GetUserByIdAsync(int id)
    {
        return await _userRepository.GetByIdAsync(id);
    }
}

The architect's role is to ensure that this blueprint serves both the business's functional and non-functional requirements.

Design: The Nitty-Gritty Details

Design is where the actual implementation happens. If architecture is the what, design is the how. While architecture decides the overall structure, design dives into the technical aspects, like which libraries to use and how classes will be structured.

For instance, in our Microservices example, design would focus on how the UserService interacts with the repository, which libraries are employed, and which coding patterns (like Dependency Injection) are used.

public interface IUserRepository
{
    Task<User> GetByIdAsync(int id);
}

public class UserRepository : IUserRepository
{
    private readonly DbContext _context;

    public UserRepository(DbContext context)
    {
        _context = context;
    }

    public async Task<User> GetByIdAsync(int id)
    {
        return await _context.Users.FindAsync(id);
    }
}

Notice how the architecture stays the same (we still have a service and a repository), but the design handles the specifics of how data is fetched from a database.

Software Architecture vs Software Design 🔍

It’s easy to confuse these terms, but they serve different purposes. To simplify:

Software Architecture is the high-level structure of a system. It deals with how the system is divided into components, how data flows between those components, and which architectural pattern (e.g. monolithic, microservices) is best suited to solve the problem.
Software Design is the low-level implementation. It focuses on fleshing out the architecture with specific libraries, technologies, and coding techniques.

Imagine you’re building a house 🏡. The architecture is like the blueprint, determining how rooms and spaces are arranged. The design, on the other hand, would be things like which materials to use for the walls, the placement of electrical wiring, and the style of windows. Both are crucial, but they address different levels of the project.

Wrapping Up 🎁

In summary:

Software Architecture focuses on the big picture: the structure, modularity, and high-level organisation of a system.
Software Design is all about the technical implementation: choosing the right tools and ensuring everything works efficiently within the architectural framework.

Understanding the history of software architecture helps us see why different patterns like Microservices or Clean Architecture emerged and how they continue to shape modern software development. 💻

In our next article (and video!), we’ll dive deeper into architectural patterns like Clean Architecture vs Microservices and discuss how they can impact your projects.

Stay tuned, and happy coding! 👨‍💻👩‍💻

DEV Community: Mo

Claude Opus 4.6 vs. GPT 5.4

Claude Opus 4.6 vs. GPT 5.4: My Take as a C#/.NET Dev on AI Coding Companions

The Setup: My C#/.NET AI Playground

GPT 5.4: The Speedy Generalist with a Few Surprises

Claude Opus 4.6: The Meticulous Architect, Slow and Steady

The Verdict: Don't Choose, Combine!

Your AI Pair Programming Partner(s)

C# Keeps Getting Better: My Favourite Modern Language Features

Streamlining Your Code: Less Ceremony, More Action!

Top-Level Statements: Kickstarting Your Apps

Global Using Directives: De-cluttering Your Files

Embracing Immutability: Records & init Setters

Record Types: The Data-First Class

init Setters: Immutable Properties, Flexible Creation

Smarter Decisions: Enhanced Pattern Matching

switch Expressions and Property Patterns

Wrapping Up

Migration from .NET 4.7 to .NET 10

Travels in Time:

The Great Migration from .NET Framework 4.7 to .NET 10 🚀

🧐 Phase 1: The Archaeology

The Initial Health Check

📋 Phase 2: The Battle Plan

🛠 Phase 3: The Upgrade (Dependencies & AI Tools)

The Third-Party Challenge

The Entity Framework Dilemma

AI vs. Legacy Tools

🏗 Phase 4: Execution

Step 1: Low-Hanging Fruit

Step 2: The Web Project (The Beast)

Step 3: The Inevitable Refactor

✅ Phase 5: Crossing the Finish Line

🔮 What's Next?

🚀 Event-Driven Architecture (EDA): The Power of Reacting to Events

🧩 What Is Event-Driven Architecture?

💡 Why EDA Matters

🧠 Key Questions to Understand EDA

🔁 Events vs. Messages

🧱 Ensuring No Data Loss

🏗️ How Many Brokers Do We Need?

🔍 Managing State in EDA

1️⃣ Push-Based Pattern

2️⃣ Pull-Based Pattern

🏁 Final Thoughts

Proper Logging in ASP.NET Core

Why Logging Matters 🤔

The Holy Trinity of Application Observability 🛠️

Implementing Logging with Serilog in ASP.NET Core 🛠️

Setting Up Serilog

Configuring Serilog

Logging in Action: GlobalExceptionHandler 🎭

Request Logging with LoggingBehaviour 🕵️

Pro Tips for Logging Like a Boss 😎

Wrapping Up 🎁

JWT Authentication & Authorization in ASP.NET

What is JWT? 🔍

How Does the Authentication & Authorization Process Work? 🛡️

Policy-Based vs. Role-Based Access Control 🔐

Role-Based Access Control (RBAC)

Policy-Based Access Control

Implementing JWT in ASP.NET Core: A Step-by-Step Guide 💻

Clone the project

Wrap-Up & Key Takeaways 📝

🚀Clean Architecture in .NET

Introduction

What is Clean Architecture? 🤔

Layer Breakdown 🏗️

Implementing Clean Architecture in .NET 🏗️

1️⃣ Domain Layer – The Heart of Clean Architecture

2️⃣ Application Layer – Business Logic & CQRS

3️⃣ Infrastructure Layer – Implementation Details

4️⃣ Presentation Layer – Exposing APIs & Dependency Injection

Key Benefits of Clean Architecture 🏆

Wrapping Up & Next Steps

Blue-Green Deployment with Azure

What is Blue-Green Deployment? 🤔

The Pros and Cons 🛠️

Pros:

Cons:

Embracing Immutability: Records & `init` Setters

`init` Setters: Immutable Properties, Flexible Creation

`switch` Expressions and Property Patterns

1. Value Type Constraint (`struct`)

2. Reference Type Constraint (`class`)

4. Constructor Constraint (`new()`)