In this article, you'll learn how to modernize legacy applications by migrating from ASP.NET Framework to ASP.NET Core. This guide covers architectural differences, migration strategies, step-by-step implementation, and best practices for building scalable, high-performance web applications.

Table of Contents

• Prerequisites

• Understanding the Architectural Shift

• Key Challenges in Migration

• Migration Strategies

• Pre-Migration Assessment

• Step-by-Step Migration Process

• Performance and Scalability Gains

• Deployment Modernization

• Common Pitfalls

• Real-World Use Cases

• Best Practices Checklist

• When You Should NOT Migrate

• Future Enhancements

• Conclusion

Legacy systems built on the ASP.NET Framework have powered enterprise applications for over a decade. While stable and mature, these systems often struggle to meet modern requirements such as cross-platform deployment, cloud-native scalability, and high-performance workloads. As businesses evolve, the need to modernize these applications becomes unavoidable.

This is where ASP.NET Core comes in. Designed as a lightweight, modular, and high-performance Framework, ASP.NET Core enables developers to build scalable applications that run on Windows, Linux, and macOS.

In this article, we’ll explore a practical and technical approach to migrating legacy ASP.NET Framework applications to ASP.NET Core MVC. Instead of focusing on theory, the emphasis will be on architectural differences, migration strategies, and step-by-step execution.

Prerequisites

Before migrating to ASP.NET Core, developers should have a solid understanding of the MVC architecture, C#, and basic .NET development concepts. Familiarity with dependency injection, REST APIs, and Entity Framework will make the migration process significantly easier.

You should also have:

• .NET SDK installed (.NET 6 or later recommended)

• Basic knowledge of CLI commands

• Experience with NuGet package management

• Understanding of IIS or web hosting environments

• A version control system such as Git

For enterprise projects, access to staging environments and automated testing pipelines is highly recommended before beginning migration.

Understanding the Architectural Shift

Migrating to ASP.NET Core is not just a version upgrade—it’s a fundamental architectural shift.

From Monolithic to Modular

ASP.NET relies heavily on the System.Web assembly, which tightly couples components such as HTTP handling, session state, and caching. In contrast, ASP.NET Core removes this dependency and introduces a modular middleware pipeline.

Built-in Dependency Injection

Dependency Injection (DI) in ASP.NET required third-party libraries like Autofac or Ninject. ASP.NET Core includes DI natively, promoting better separation of concerns.

Unified Runtime

ASP.NET Core runs on the modern .NET ecosystem (for example, .NET 6+), which unifies previously fragmented runtimes and improves performance.

Configuration Overhaul

Configuration has moved from XML-based web.config files to flexible JSON-based systems like appsettings.json, supporting environment-specific configurations.

Key Challenges in Migration

Before diving into the process, it’s important to understand the challenges:

• Tightly coupled codebases: Legacy applications often mix business logic, UI, and data access.

• Unsupported APIs: Some APIs used in ASP.NET are not available in Core.

• Third-party dependencies: Older libraries may not support .NET Core.

• Authentication differences: Forms authentication and legacy identity systems require refactoring.

• Large monoliths: Breaking down large applications is time-consuming.

Ignoring these challenges often leads to failed or incomplete migrations.

Migration Strategies

Choosing the right migration approach is critical.

Big Bang Migration

This approach involves rewriting the entire application at once.

Pros:

• Clean architecture

• No legacy baggage

Cons:

• High risk

• Long timelines

• Requires full regression testing

This approach is rarely recommended for large systems.

Incremental Migration (Recommended)

The Strangler Fig Pattern is commonly used here. New features are built in ASP.NET Core while gradually replacing legacy components.

The Strangler Fig Pattern is named after a vine that grows around a host tree and gradually replaces it over time. In software modernization, this pattern involves building new functionality alongside the existing application and routing specific requests to the new system as components are migrated. Instead of replacing the entire application at once, teams incrementally “strangle” the legacy system until the new ASP.NET Core application fully takes over.

Benefits:

• Reduced risk

• Continuous delivery

• Easier debugging

Hybrid Approach

Run ASP.NET Framework and ASP.NET Core side by side. Certain modules (for example, APIs) can be migrated first while the UI remains unchanged.

Pros:

• Lower migration risk

• Minimal disruption

• Supports phased rollout

Cons:

• Increased operational complexity

• Additional deployment overhead

• Temporary architectural duplication

This approach is especially useful for large enterprise systems where maintaining business continuity is more important than completing the migration quickly.

Pre-Migration Assessment

A successful migration starts with proper planning.

Codebase Audit

• Identify reusable modules

• Detect tightly coupled components

• Analyze dependencies

Tooling Support

Use tools like:

• .NET Portability Analyzer

• API analyzers

These help determine compatibility with ASP.NET Core.

Define Scope

Decide what to migrate first:

• APIs

• UI (MVC Views)

• Background services

Step-by-Step Migration Process

Step 1: Upgrade Existing Application

Ensure your application is running on the latest version of ASP.NET Framework. This minimizes compatibility issues.

Step 2: Create a New ASP.NET Core MVC Project

Use the CLI:

dotnet new mvc -n ModernApp

This creates a clean project with a modern structure:

• Program.cs (entry point)

• Controllers/

• Views/

• wwwroot/

Step 3: Migrate Configuration

Replace web.config with appsettings.json.

Old (web.config):

<appSettings>
  <add key="ApiUrl" value="https://api.example.com" />
</appSettings>

New (appsettings.json):

{
  "ApiSettings": {
    "BaseUrl": "https://api.example.com"
  }
}

Access in code:

public class HomeController : Controller
{
    private readonly IConfiguration _config;

    public HomeController(IConfiguration config)
    {
        _config = config;
    }

    public IActionResult Index()
    {
        var url = _config["ApiSettings:BaseUrl"];
        return View();
    }
}

Step 4: Replace Global.asax with Middleware

ASP.NET Core uses a middleware pipeline instead of lifecycle events.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseRouting();
app.UseAuthorization();

app.MapControllers();

app.Run();

This pipeline provides more control and flexibility compared to the old event-driven model.

Step 5: Migrate Controllers and Views

Controller logic remains similar, but return types change.

ASP.NET Framework:

public ActionResult Index()
{
    return View();
}

ASP.NET Core:

public IActionResult Index()
{
    return View();
}

Views (Razor) require minor updates, especially for tag helpers.

Step 6: Implement Dependency Injection

Replace tightly coupled services with DI.

public interface IProductService
{
    List<string> GetProducts();
}

public class ProductService : IProductService
{
    public List<string> GetProducts()
    {
        return new List<string> { "Laptop", "Phone" };
    }
}

Register service:

builder.Services.AddScoped<IProductService, ProductService>();

Use in controller:

public class ProductController : Controller
{
    private readonly IProductService _service;

    public ProductController(IProductService service)
    {
        _service = service;
    }

    public IActionResult Index()
    {
        var products = _service.GetProducts();
        return View(products);
    }
}

Step 7: Migrate Data Access Layer

Most legacy apps use Entity Framework. In ASP.NET Core, you’ll use Entity Framework Core.

DbContext Example:

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options) { }
}

Register in Program.cs:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer("YourConnectionString"));

Step 8: Authentication and Authorization

ASP.NET Core provides flexible authentication mechanisms:

• Cookie-based authentication

• JWT tokens

• OAuth providers

Example:

builder.Services.AddAuthentication("CookieAuth")
    .AddCookie("CookieAuth", config =>
    {
        config.LoginPath = "/Account/Login";
    });

Step 9: Testing and Validation

Testing becomes critical during migration:

• Unit testing (xUnit, NUnit)

• Integration testing

• Regression testing

Ensure feature parity between old and new systems.

For example, after migrating a legacy ASP.NET Framework API to ASP.NET Core, you can validate behavior using integration tests to ensure responses match the original system.

Example: Integration Test (xUnit)

[Fact]
public async Task GetProducts_ShouldReturnSuccessStatus()
{
    // Arrange
    var client = _factory.CreateClient();

    // Act
    var response = await client.GetAsync("/api/products");

    // Assert
    response.EnsureSuccessStatusCode();
}

You can also compare legacy and migrated endpoints side by side during transition:

• /legacy/api/products → ASP.NET Framework

• /api/products → ASP.NET Core

Then run parallel requests and validate response consistency in structure, status codes, and data integrity. This helps ensure that migration does not introduce behavioral regressions before fully decommissioning the legacy system.

Performance and Scalability Gains

ASP.NET Core introduces significant improvements:

• Kestrel Web Server: High-performance, cross-platform server

• Async-first design: Efficient request handling

• Lower memory usage

• Better throughput under load

These improvements make it ideal for microservices and cloud deployments.

Deployment Modernization

Legacy applications were traditionally tightly coupled to IIS-based hosting environments, which limited flexibility in deployment and scaling. With ASP.NET Core, applications can now be deployed using modern, portable, and automated infrastructure approaches that better support cloud-native development and continuous delivery.

Containerization

Containerization allows applications to be packaged with all their dependencies into a single, portable unit that can run consistently across different environments. With tools like Docker, ASP.NET Core applications can be deployed reliably across development, staging, and production without environment-specific configuration issues. This approach also simplifies scaling and rollback strategies in distributed systems.

FROM mcr.microsoft.com/dotnet/aspnet:6.0
COPY . /app
WORKDIR /app
ENTRYPOINT ["dotnet", "ModernApp.dll"]

CI/CD Integration

Continuous Integration and Continuous Deployment (CI/CD) pipelines automate the process of building, testing, and deploying applications. In migration scenarios, CI/CD becomes especially important because it ensures that both legacy and modernized components remain stable during incremental rollout. Platforms like GitHub Actions and Azure DevOps help teams validate changes quickly and reduce the risk of regression when transitioning from ASP.NET Framework to ASP.NET Core.

Using CI/CD also enables:

• Faster release cycles during phased migration

• Automated testing of migrated modules

• Safe rollback in case of deployment failures

This ensures automated builds, tests, and deployments.

Common Pitfalls

Underestimating Complexity

Migration is not just about converting code—it involves rethinking the entire architecture. Differences in middleware, configuration, and hosting models mean teams must redesign key components rather than simply port them.

Ignoring Dependencies

Many legacy applications rely on third-party libraries that may not support ASP.NET Core. Failing to assess compatibility early can lead to blockers, forcing last-minute rewrites or replacements.

Skipping Incremental Approach

Attempting a full “Big Bang” migration increases risk and often results in delays or failures. An incremental strategy allows teams to validate changes gradually and maintain system stability throughout the transition.

Poor Testing

Insufficient testing can introduce critical bugs into production systems. Comprehensive unit, integration, and regression testing are essential to ensure the new application matches the behavior of the legacy system.

Real-World Use Cases

Enterprise ERP Modernization

Large ERP systems built on ASP.NET often become difficult to scale and maintain due to tightly coupled architectures. Migrating these systems to ASP.NET Core allows organizations to modularize components, improve performance, and enable cloud deployment. This transition also makes it easier to introduce microservices and modern DevOps practices.

E-commerce Platform Scaling

E-commerce applications require high availability and the ability to handle traffic spikes. By moving to ASP.NET Core, businesses can take advantage of asynchronous processing, improved request handling, and container-based scaling. This ensures faster page loads, better user experience, and the ability to handle peak demand efficiently.

API-First Backend Transformation

Modern applications increasingly adopt an API-first approach, where the backend is designed as a set of independent services. ASP.NET Core simplifies building RESTful APIs with better routing, serialization, and performance. Organizations often migrate APIs first to establish a scalable backend, then gradually transition UI layers to align with the new architecture.

Best Practices Checklist

Start with a Small Module

Instead of migrating the entire application at once, begin with a low-risk module such as a reporting feature or internal API. This helps teams understand the migration process, identify challenges early, and build confidence before scaling the effort across the system.

Use Incremental Migration

An incremental approach, such as the Strangler Fig pattern, allows legacy and modern systems to coexist during the transition. This reduces downtime, minimizes risk, and ensures continuous delivery while gradually replacing legacy components with ASP.NET Core services.

Refactor for Dependency Injection Early

Dependency injection is a core principle in ASP.NET Core, and adopting it early simplifies future development. Refactoring tightly coupled components into loosely coupled services improves testability, maintainability, and overall code quality during and after migration.

Monitor Performance Continuously

Performance should be tracked throughout the migration process using logging and monitoring tools. Comparing metrics between the legacy system and the new implementation helps validate improvements and ensures that performance regressions are identified and addressed quickly.

Maintain Backward Compatibility

During migration, it is essential to ensure that existing clients and integrations continue to function correctly. Maintaining backward compatibility through versioned APIs or adapters allows a smooth transition without disrupting users or dependent systems.

When You Should NOT Migrate

Migration is not always the right decision. If a legacy application is stable, rarely updated, and meeting business requirements, a full migration may not justify the cost and engineering effort. Some enterprise systems also depend heavily on Windows-specific technologies or third-party libraries that have no ASP.NET Core equivalents.

You should avoid immediate migration when:

• Business risk outweighs modernization benefits

• The application is nearing retirement

• Critical dependencies are unsupported in .NET Core

• The team lacks resources for testing and refactoring

• Downtime or instability could severely impact operations

In such cases, maintaining the existing system while gradually modernizing specific modules may be a more practical strategy.

Future Enhancements

As organizations continue modernizing applications with ASP.NET Core, future enhancements often focus on scalability, automation, and cloud-native development practices. Migrating to ASP.NET Core creates a foundation that makes it easier to adopt newer architectural patterns and infrastructure technologies.

Microservices Adoption

After migration, many organizations gradually break large monolithic systems into microservices. This improves scalability, fault isolation, and independent deployment of application components while enabling faster development cycles.

Cloud-Native Deployment

ASP.NET Core applications are well-suited for deployment on cloud platforms such as Microsoft Azure, Amazon Web Services (AWS), and Google Cloud. Future enhancements may include auto-scaling, serverless workloads, and managed container orchestration.

Container Orchestration with Kubernetes

Containerized ASP.NET Core applications can be managed using Kubernetes for automated scaling, service discovery, and high availability. This is especially useful for enterprise-grade distributed systems.

Advanced Observability and Monitoring

Modern systems increasingly integrate observability platforms such as centralized logging, distributed tracing, and performance monitoring. Tools like Prometheus and Grafana help teams proactively detect issues and optimize performance.

API Gateway and Service Mesh Integration

As applications evolve into distributed architectures, API gateways and service meshes become valuable for traffic management, authentication, and security. This enhances communication between services while improving resilience and governance.

AI-Assisted Development and Automation

Modern .NET ecosystems increasingly integrate AI-powered coding assistants, automated testing, and intelligent CI/CD pipelines. These tools can reduce development time, improve code quality, and simplify long-term maintenance of migrated applications.

Conclusion

Migrating from ASP.NET Framework to ASP.NET Core MVC is a strategic modernization effort, not just a technical upgrade. While the process involves challenges—ranging from architectural changes to dependency issues—the long-term benefits are substantial.

By adopting an incremental approach, leveraging modern tools, and focusing on clean architecture, organizations can successfully transition to a platform built for performance, scalability, and cloud-native development.

ASP.NET Core is not just the future of .NET—it’s the foundation for building resilient, modern applications in today’s distributed world.

DynamoDB isn't a relational database, it's a NoSQL key-value and document store. You don't write arbitrary queries against your data. Instead, you design your tables around the specific access patterns your application needs.

DynamoDB is driven by your queries, not your data.

There's no need for joins or heavy normalisation. To get the performance DynamoDB is built for, model your data so it can be retrieved efficiently using keys – partition keys and sort keys – rather than relying on table scans or complex query logic.

If you try to use DynamoDB like SQL, it will fight you — and you will lose.

Prerequisites

There are a few things you'll need and some general knowledge that you should have to follow along most effectively here:

AWS

• An active AWS account with permissions to create and modify DynamoDB

• Basic familiarity with the AWS Console (navigating services, not deep expertise)

C# / .NET

• Comfortable with C#

• Dependency injection

• NuGet package management — you'll need to install AWSSDK.DynamoDBv2

Databases (Conceptual)

• (Optional) A working understanding of relational databases / SQL is actually helpful here — the article explicitly addresses readers coming from that background and explains the mental shift required

What you don't need

• Prior DynamoDB experience — the article covers core concepts from scratch

• Deep AWS infrastructure knowledge — IAM, VPCs, and so on aren't covered

Optional but useful

• AWS CLI installed locally if you want to follow the AWS CLI examples directly

• Terraform experience if following the infrastructure-as-code example (Terraform section can be skipped without losing context)

Table Of Contents

• Core DynamoDB Concepts

  • Partition Key

  • Sort Key (Optional)

  • Global Secondary Index (GSI)

• Synthetic Keys — The Old Way

• Multi-Attribute GSIs — The New Way

  • Defining a Multi-Attribute GSI

  • Query Rules You Must Follow

• C# SDK Options

  • Low-Level Client

  • Document Model

  • Object Persistence Model

  • Setting Up the Context

• Querying a Multi-Attribute GSI from C

• Query vs Scan

  • Query

  • Scan

  • When Is A Scan Acceptable?

• Filter Expressions

• Paging Results and User Interfaces

  • How It Works in DynamoDB

  • How This Works In The DynamoDB C# SDK

  • Manual Pagination — The Right Approach For UIs

  • What About "go to to page 7" Navigation?

  • The FilterExpression Trap

• Final Thoughts & Conclusion

Core DynamoDB Concepts

DynamoDB is built around a few core concepts that directly influence how you query and structure your data.

Remember: DynamoDB is driven by how you retrieve your data, not by the shape of the data itself.

Partition Key

• Required for every query

• Required to create a table – each table must have a partition key

• Determines data distribution and how items are stored

Data in DynamoDB is physically distributed across partitions. The partition key decides where a given item lives, which is why it's critical for both performance and scalability.

You can think of a partition key like a filing cabinet drawer label: it tells DynamoDB which drawer to open so it can go straight to your data without searching every drawer.

Partition keys are typically strings or numbers.

Sort Key (Optional)

Also known as the Range Key.

• Enables range queries (between, begins_with, and so on)

When you add a sort key, items with the same partition key are grouped together and ordered by the sort key. For string sort keys, ordering is lexicographical (dictionary order). For numeric sort keys, ordering is numeric (ascending).

This has an important effect when working with dates. If you store dates as strings in a non-ISO format (for example, DD/MM/YYYY), they won't sort in chronological order. For example, the resulting sorted items would look like this:

01/01/2026
01/02/2026
01/03/2026
08/01/2026
15/02/2026

Here, all dates starting with 01 are grouped together, even though they span different months. This breaks range queries and ordering.

To avoid this, use either:

• ISO 8601 format (YYYY-MM-DD), which sorts correctly as a string

• Unix timestamps (typically milliseconds since January 1st, 1970), which sort numerically and correctly

Both approaches ensure your data is ordered correctly and can be queried efficiently. This is commonly used for timestamps, versioning, or logical groupings (for example, ORDER#2024-01).

Global Secondary Index (GSI)

A Global Secondary Index (GSI) allows you to query your data using a different partition key and optional sort key than your base table. This is how you support additional access patterns without redesigning your primary key schema.

For example, if your base table is keyed by UserId, but you also need to query by OrderId, a GSI makes that possible.

Projection Types

A GSI doesn't have to include all attributes from the base table. When configuring your GSI you can choose:

• ALL — all attributes are projected

• KEYS_ONLY — only index and primary keys

• INCLUDE — a subset of selected attributes

Choosing the right projection helps reduce storage and read costs. For example, for an orders view you could project only orderNumber, dateOrdered, and cost rather than all other attributes which aren't needed.

Important Considerations

Additional cost: GSIs consume their own read/write capacity and storage in addition to your base table's costs. Using ProjectionType = INCLUDE or KEYS_ONLY instead of ALL reduces the storage cost of the GSI since less data is duplicated into the index, which can offset the additional read/write cost.

Eventual consistency: In DynamoDB, when you write directly to the base table you have the option to perform a strongly consistent read immediately after — meaning you're guaranteed to get the latest data. GSIs don'r support this. GSI reads are always eventually consistent.

When a customer places an order, DynamoDB writes that order to your main Orders table. It then replicates that change to any GSIs asynchronously in the background. During that brief window (typically milliseconds), a query against a GSI may not return the newly written order yet.

A real-world example of where this can catch you out:

1. Customer places an order which is written to the Orders table

2. User is redirected to the "Your Orders" page

3. "Your Orders" page queries a GSI for all orders by this customer

4. New order doesn't appear yet — GSI replication is still in progress

5. Customer refreshes the page 50ms later

6. Order now appears

For most queries — browsing a product catalogue, viewing order history, filtering by status — this is completely acceptable and unnoticeable to the user. Where it matters is when your application writes a record and immediately queries a GSI for that same record. In this scenario you have a couple of options:

• Query the base table directly after a write using a strongly consistent read, rather than the GSI

• Pass the order data directly to the UI from the write response, without a follow-up query at all — the cleanest solution in most cases

Write amplification: Every write to the base table may also write to one or more GSIs. GSIs are powerful, but they're not free. Overusing them is often a sign that your primary access patterns weren't well defined upfront.

Note: DynamoDB allows a maximum of 20 GSIs per table by default, though this can be increased via an AWS service limit request.

Synthetic Keys — The Old Way

Before we look at multi-attribute GSIs, it's worth understanding the pattern they replace — because you'll encounter it in existing DynamoDB codebases.

Imagine you want to query orders by both status and date — for example, all "pending" orders placed in the last 30 days. Previously, DynamoDB GSIs only supported a single attribute as the partition key and a single attribute as the sort key. To filter on multiple attributes you had to combine them into a single synthetic attribute:

[DynamoDBTable("Orders")]
public class OrderDto
{
    [DynamoDBHashKey("customerId")]
    public string CustomerId { get; set; }

    [DynamoDBRangeKey("createdAt")]
    public long CreatedAt { get; set; }

    [DynamoDBProperty("orderId")]
    public string OrderId { get; set; }

    [DynamoDBProperty("status")]
    public string Status { get; set; }

    // Synthetic key — manually constructed before saving
    [DynamoDBProperty("statusDate")]
    public string StatusDate { get; set; } // e.g. "PENDING#2025-11-01"
}

Constructing this value before saving the record:

order.StatusDate = $"{order.Status}#{order.CreatedAt:yyyy-MM-dd}";

Then create a GSI on statusDate as the partition key, allowing you to query:

var results = await _context.QueryAsync<OrderDto>(
    "PENDING#2025-11-01",
    config // IndexName = "statusDate-index"
).GetRemainingAsync();

This worked, but came with real downsides:

• Brittle — every developer writing to the table must know about and correctly format the synthetic key

• Hard to query ranges — filtering all pending orders across a date range required careful begins_with or between conditions on a concatenated string

• Maintenance overhead — if status values change, every existing record needs updating

• Invisible in the schema — a new developer has no idea what statusDate means without documentation

• Backfilling — adding a new synthetic-key GSI to an existing table meant updating every existing record to populate the new attribute via a script re-processing the existing items.

Multi-Attribute GSIs — The New Way

On November 19, 2025, AWS announced multi-attribute composite keys for GSIs. You can now define a GSI partition key or sort key comprised of up to 4 attributes each — 8 attributes in total across the partition and sort key combined.

A few important things to note:

• GSIs only: This applies to GSIs only — your base table primary key structure is unchanged, still a single partition key and an optional single sort key.

• DynamoDB handles composition internally: You don't concatenate values yourself. DynamoDB hashes the partition key attributes together for data distribution, and maintains hierarchical sort order across the sort key attributes.

• Strict query rules still apply: You must supply all partition key attributes with equality conditions when querying. Sort key attributes must be queried left-to-right in the order they were defined — you can't skip attributes.

• No backfilling required. When you add a multi-attribute GSI to an existing table, DynamoDB automatically indexes all existing items using their natural attributes.

• No additional cost beyond standard GSI pricing.

The model stays clean — no synthetic attributes needed:

[DynamoDBTable("Orders")]
public class OrderDto
{
    [DynamoDBHashKey("customerId")]
    public string CustomerId { get; set; }

    [DynamoDBRangeKey("createdAt")]
    public long CreatedAt { get; set; }

    [DynamoDBProperty("orderId")]
    public string OrderId { get; set; }

    [DynamoDBProperty("status")]
    public string Status { get; set; }

    [DynamoDBProperty("total")]
    public decimal Total { get; set; }
}

Defining a Multi-Attribute GSI

You can create the GSI via the AWS Console (select the attributes you want in order), via Terraform (requires AWS provider v6.29.0+), or via the AWS CLI.

The key concept to understand: you provide multiple HASH entries for the composite partition key and multiple RANGE entries for the composite sort key, in the exact order they should be evaluated. DynamoDB treats them internally as one composite partition key and one composite sort key.

Here's an AWS CLI example — a GSI on Orders with a composite partition key (customerId + status) and a single-attribute sort key (createdAt):

aws dynamodb update-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=customerId,AttributeType=S \
    AttributeName=status,AttributeType=S \
    AttributeName=createdAt,AttributeType=N \
  --global-secondary-index-updates \
  "[{\"Create\":{
    \"IndexName\":\"customerStatus-createdAt-index\",
    \"KeySchema\":[
      {\"AttributeName\":\"customerId\",\"KeyType\":\"HASH\"},
      {\"AttributeName\":\"status\",\"KeyType\":\"HASH\"},
      {\"AttributeName\":\"createdAt\",\"KeyType\":\"RANGE\"}
    ],
    \"Projection\":{\"ProjectionType\":\"ALL\"}
  }}]"

The two HASH entries here are valid. They define a composite partition key of (customerId, status). This is the syntax AWS introduced specifically for multi-attribute GSIs. It would have been rejected before November 2025.

Here's a Terraform example (AWS provider v6.29.0+):

global_secondary_index {
  name            = "customerStatus-createdAt-index"
  projection_type = "ALL"

  key_schema {
    attribute_name = "customerId"
    key_type       = "HASH"
  }

  key_schema {
    attribute_name = "status"
    key_type       = "HASH"
  }

  key_schema {
    attribute_name = "createdAt"
    key_type       = "RANGE"
  }
}

Query Rules You Must Follow

The flexibility gain with multi-attribute GSIs is real, but the query constraints are not the same as SQL. Two rules matter most:

1. Partition key attributes must all be supplied, with equality only.

For a partition key of (customerId, status):

Valid:

customerId = 'C123' AND status = 'PENDING'

Invalid — missing status:

customerId = 'C123'

Invalid — inequality on a partition key attribute:

customerId = 'C123' AND status > 'P'

2. Sort key attributes must be queried left-to-right, with inequality only as the final condition.

For a sort key of (tournamentRound, rank, matchId):

Valid:

tournamentRound = 'SEMIFINALS'

tournamentRound = 'SEMIFINALS' AND rank = 'UPPER'

tournamentRound = 'SEMIFINALS' AND rank = 'UPPER' AND matchId = 'match-002'

tournamentRound = 'SEMIFINALS' AND rank = 'UPPER' AND matchId > 'match-001'

tournamentRound BETWEEN 'QUARTERFINALS' AND 'SEMIFINALS'

Invalid — skipping the first attribute:

rank = 'UPPER'

Invalid — leaving a gap (skipping bracket)

tournamentRound = 'SEMIFINALS' AND matchId = 'match-002'

Invalid — adding a condition after an inequality:

tournamentRound > 'QUARTERFINALS' AND rank = 'UPPER'

Design tip: Order your sort key attributes from most general to most specific for example, tournamentRound → rank → matchId). This maximises query flexibility, since each left-to-right prefix becomes a valid query pattern.

Going deeper:

AWS publishes a detailed design pattern guide with worked examples for time-series data, e-commerce orders, hierarchical organisation data, and multi-tenant SaaS platforms. The examples use the JavaScript SDK, but the schema design principles apply regardless of language. The article can be found here.

C# SDK Options

When working with DynamoDB in C#, the AWSSDK.DynamoDBv2 NuGet package gives you three different ways to interact with your tables, each with different levels of abstraction.

Low-Level Client

var client = new AmazonDynamoDBClient();

The AmazonDynamoDBClient gives you full control over every aspect of your DynamoDB interactions. You construct requests manually, specifying every attribute, condition, and configuration explicitly.

var request = new QueryRequest
{
    TableName = "Orders",
    KeyConditionExpression = "customerId = :customerId",
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        { ":customerId", new AttributeValue { S = "customer-123" } }
    }
};

var response = await client.QueryAsync(request);

This is the most verbose approach, but nothing is hidden from you. You can see exactly what's being sent to DynamoDB, which makes it easier to debug, optimise, and understand exactly what Read Capacity Units (RCUs) you're consuming. It's also the most flexible — anything DynamoDB supports, you can do here.

When to use it:
When you need fine-grained control, are doing something complex, or want full visibility into your queries.

Document Model

var client = new AmazonDynamoDBClient();
var table = Table.LoadTable(client, "Orders");

The Document Model sits a level above the low-level client. Rather than working with raw AttributeValue types, you work with Document objects which feel more like JSON — familiar to most .NET developers.

var filter = new QueryFilter("customerId", QueryOperator.Equal, "customer-123");
var search = table.Query(filter);
var documents = await search.GetRemainingAsync();

// access the data
foreach (var doc in documents)
{
    Console.WriteLine(doc["orderId"].AsString());
    Console.WriteLine(doc["total"].AsDecimal());
}

Less boilerplate than the low-level client, but you're still working with loosely typed Document objects rather than your own C# classes. There's no mapping to strongly typed models out of the box.

When to use it:
Useful for dynamic or loosely structured data where you don't want to define a fixed model, or for quick tooling and scripts.

Object Persistence Model

The Object Persistence Model is the highest level of abstraction and the most natural fit for typical .NET development.

You decorate your C# classes with attributes, and the DynamoDBContext handles serialisation and deserialisation automatically — similar to an ORM like Entity Framework.

[DynamoDBTable("Orders")]
public class OrderRecord
{
    [DynamoDBHashKey("customerId")]
    public string CustomerId { get; set; }

    [DynamoDBRangeKey("createdAt")]
    public long CreatedAt { get; set; }

    [DynamoDBProperty("orderId")]
    public string OrderId { get; set; }

    [DynamoDBProperty("total")]
    public decimal Total { get; set; }

    [DynamoDBProperty("status")]
    public string Status { get; set; }
}

Querying feels clean and strongly typed:

var orders = await dbContext
    .QueryAsync<OrderRecord>("customer-123")
    .GetRemainingAsync();

The trade-off is that the abstraction hides some important details: you don't always see exactly what's being sent to DynamoDB under the hood, which can make debugging and performance optimisation harder.

Setting Up the Context

When creating the db context there are a couple of options:

Option 1 — using Dependency Injection:

// Program.cs
builder.Services.AddSingleton<IAmazonDynamoDB, AmazonDynamoDBClient>();

builder.Services.AddSingleton<IDynamoDBContext>(sp =>
{
    var client = sp.GetRequiredService<IAmazonDynamoDB>();
    return new DynamoDBContext(client);
});

// Then in repository / service, inject IDynamoDBContext
public class OrderRepository
{
    private readonly IDynamoDBContext _context;

    public OrderRepository(IDynamoDBContext context)
    {
        _context = context;
    }
}

Option 2 — register AmazonDynamoDBClient only, and instantiate the context per operation:

// Program.cs
builder.Services.AddSingleton<IAmazonDynamoDB, AmazonDynamoDBClient>();

Then:

public class OrderRepository
{
    private readonly IAmazonDynamoDB _client;

    public OrderRepository(IAmazonDynamoDB client)
    {
        _client = client;
    }

    public async Task<List<OrderDto>> GetOrdersAsync(string customerId)
    {
        var context = new DynamoDBContext(_client); // lightweight to instantiate
        return await context.QueryAsync<OrderDto>(customerId).GetRemainingAsync();
    }
}

Which is better? Option 1 is cleaner and more testable — you can mock IDynamoDBContext in unit tests easily. Option 2 is also valid since DynamoDBContext is lightweight to instantiate, but you lose the ability to mock it cleanly.

When to use Object Persistence: the recommended approach for most .NET applications. Clean, strongly typed, and fits naturally into existing C# codebases.

Querying a Multi-Attribute GSI From C#

At the time of writing, the DynamoDBContext.QueryAsync<T> convenience overloads don't support multi-attribute GSI key conditions directly — you need to use the low-level client (IAmazonDynamoDB) and pass a KeyConditionExpression. The good news is the deserialisation back to your typed model is still straightforward.

Here's a query against a GSI with a composite partition key of (customerId, status) and a sort key of createdAt, returning all pending orders for a customer since a given date:

public async Task<List<OrderDto>> GetOrdersByStatusSinceAsync(
    string customerId,
    string status,
    long fromDate)
{
    var request = new QueryRequest
    {
        TableName = "Orders",
        IndexName = "customerStatus-createdAt-index",
        KeyConditionExpression =
            "customerId = :customerId " +
            "AND #status = :status " +           // #status because 'status' is a reserved word
            "AND createdAt > :fromDate",
        ExpressionAttributeNames = new Dictionary<string, string>
        {
            { "#status", "status" }
        },
        ExpressionAttributeValues = new Dictionary<string, AttributeValue>
        {
            { ":customerId", new AttributeValue { S = customerId } },
            { ":status",     new AttributeValue { S = status } },
            { ":fromDate",   new AttributeValue { N = fromDate.ToString() } }
        },
        ScanIndexForward = false // reverse sort key order — newest first, since sort key is a timestamp
    };

    var response = await _client.QueryAsync(request);

    // manually deserialise back to OrderDto using the DynamoDBContext
    return _context.FromDocuments<OrderDto>(
        response.Items.Select(Document.FromAttributeMap)
    ).ToList();
}

Looking at the code above, notice that:

• Both partition key attributes (customerId and status) are supplied with equality — this is required.

• The sort key (createdAt) uses an inequality > (greater than) as the final condition, which is allowed.

• No synthetic string construction, no brittle formatting conventions, no backfilling existing records.

If you're working on an existing codebase that uses synthetic keys, it's worth evaluating whether migrating to multi-attribute GSIs makes sense. The backfilling problem that made migrations painful before is gone, DynamoDb multi-attribute GSIs handle it automatically.

Query vs Scan

This is one of the most important concepts to understand when working with DynamoDB — and one of the most common sources of performance and cost problems.

Query

A Query retrieves items using the partition key, and optionally narrows results using the sort key. DynamoDB knows exactly which partition to look in, reads only the relevant items, and returns them efficiently.

// Get all orders for a customer
var orders = await _context
    .QueryAsync<OrderDto>("customer-123")
    .GetRemainingAsync();

You can narrow further using a sort key condition — for example, all orders placed in the last 30 days:

var thirtyDaysAgo = DateTimeOffset.UtcNow.AddDays(-30).ToUnixTimeMilliseconds();

var orders = await _context.QueryAsync<OrderDto>(
    "customer-123",
    QueryOperator.GreaterThan,
    new List<object> { thirtyDaysAgo }
).GetRemainingAsync();

Queries are fast and cheap — you only pay RCUs for the records actually read.

Scan

A Scan reads every single item in the table, then filters the results. It doesn't use keys or indexes — it brute-forces through everything.

var conditions = new List<ScanCondition>
{
    new ScanCondition("status", ScanOperator.Equal, "pending")
};

var orders = await _context
    .ScanAsync<OrderDto>(conditions)
    .GetRemainingAsync();

This works — but on a table with 10 million orders, DynamoDB reads all 10 million records and then filters down to the pending ones. You pay RCUs for every single record read, not just the ones returned.

Important: Scans should be avoided in production for large tables. They're slow, expensive, and get worse as your table grows.

The difference visualised:

Query:
Table [■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■]
       └── Jump straight to partition "customer-123"
               └── Read only these items — cheap

Scan:
Table [■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■]
       └── Read every single item — expensive
               └── Then discard non-matching items

When Is A Scan Acceptable?

Scans aren't always wrong — there are legitimate use cases:

• Small tables — a lookup table with 50 items, a scan is perfectly fine

• One-off data migrations or admin scripts — not user-facing, run occasionally

• Development and debugging — scanning locally or against a small dataset

Rule of thumb: if it's a user-facing query on a growing table, it should be a Query, not a Scan.

Coming from SQL, developers often reach for a Scan because it feels like:

SELECT * FROM orders WHERE status = 'pending'

In SQL with a good index, that's fine. In DynamoDB, without a GSI on status, that's a full table scan every time. The solution is to design a GSI for the access patterns you need — exactly what we covered in the GSI section earlier.

Filter Expressions

Both Query and Scan support an optional FilterExpression — a condition applied after DynamoDB has read the records but before they're returned to you. It looks superficially like a SQL WHERE clause, and that's exactly the trap.

var request = new QueryRequest
{
    TableName = "Orders",
    KeyConditionExpression = "customerId = :customerId",
    FilterExpression = "#status = :status",
    ExpressionAttributeNames = new Dictionary<string, string>
    {
        { "#status", "status" }
    },
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        { ":customerId", new AttributeValue { S = "customer-123" } },
        { ":status",     new AttributeValue { S = "pending" } }
    }
};

The critical thing to understand: FilterExpression does not reduce the cost of the query. DynamoDB still reads every record first, charges you RCUs for all of them, and only then discards the ones that don't match the filter.

For a Query, that means every record matched by the KeyConditionExpression. For a Scan, that means every record in the table.

It's a convenience for trimming the response payload, not a tool for efficient querying. If you find yourself reaching for FilterExpression to support a real access pattern, that's a signal you need a GSI instead.

Paging Results and User Interfaces

Pagination is one of the most misunderstood aspects of DynamoDB, especially if you're coming from a SQL background.

In SQL you might write:

SELECT * FROM orders LIMIT 10 OFFSET 20

DynamoDB doesn't work like this. There is no concept of OFFSET or page numbers. Instead, DynamoDB uses cursor-based pagination via a LastEvaluatedKey.

How It Works In DynamoDB

DynamoDB returns a maximum of 1MB of data per request. If your results exceed 1MB, DynamoDB returns a LastEvaluatedKey — a pointer to where it stopped reading. Pass this back in to the next request to continue from that position. When no LastEvaluatedKey is returned, you've reached the end of the data.

How This Works In The DynamoDB C# SDK

The SDK's GetRemainingAsync() method handles pagination automatically, it keeps making requests until there is no LastEvaluatedKey left, returning everything as a single list:

// Handles all pages automatically — but loads everything into memory
var orders = await _context
    .QueryAsync<OrderDto>("customer-123")
    .GetRemainingAsync();

This is convenient but dangerous on large datasets. If a customer has 50,000 orders, you're loading all 50,000 into memory in one go.

Manual Pagination — The Right Approach For UIs

For a UI with "load more" or "next/previous" navigation, control pagination manually using GetNextSetAsync():

// ---- Paging Model ----
public class PagedResult<T>
{
    public List<T> Items { get; set; }
    public string? PaginationToken { get; set; }
}

// ---- Repository Method ----
public async Task<PagedResult<OrderDto>> GetOrdersPageAsync(
    string customerId,
    string? paginationToken = null)
{
    var config = new DynamoDBOperationConfig
    {
        BackwardQuery = true // reverse sort key order — newest first if sort key is a timestamp
    };

    var search = _context.QueryAsync<OrderDto>(customerId, config);

    if (paginationToken != null)
        search.PaginationToken = paginationToken;

    var items = await search.GetNextSetAsync(25); // fetch exactly 25 records

    return new PagedResult<OrderDto>
    {
        Items = items,
        PaginationToken = search.PaginationToken // null if no more pages
    };
}

The PaginationToken is the SDK's serialised representation of the LastEvaluatedKey — pass it directly to the client as a string and receive it back on the next request.

What About "go to to page 7" Navigation?

This isn't possible in DynamoDB. The LastEvaluatedKey is a position cursor, to reach page 7 you'd have to paginate through pages 1 to 6 first to obtain the correct cursor placement.

For most modern UIs this isn't a problem. Infinite scroll and "load more" patterns map naturally to cursor-based pagination.

The FilterExpression Trap

We've already seen that FilterExpression is a poor substitute for a well-designed GSI. Pagination is where it goes from "wasteful" to actively broken.

DynamoDB's pagination works in two stages when a FilterExpression is involved:

1. Read records until the 1MB limit is reached

2. Apply the FilterExpression, discarding non-matching records

The LastEvaluatedKey is generated after step 1 — before filtering. So DynamoDB can return a LastEvaluatedKey implying there are more results, even if the filtered page returned only a handful of records.

With 1,000 orders where only 50 are "pending":

Page 1: Read 200 records → filter applied → 3 "pending" returned + LastEvaluatedKey

Page 2: Read 200 records → filter applied → 1 "pending" returned + LastEvaluatedKey

Page 3: Read 200 records → filter applied → 0 "pending" returned + LastEvaluatedKey

...and so on until all 1,000 records are read

Important: You pay RCUs for every record read, NOT every record returned.

The Limit parameter doesn't rescue you here. GetNextSetAsync(25) caps the records read before filtering, not the records returned. You can read 25, filter down to 3, and still get a LastEvaluatedKey back, meaning your "page size of 25" actually returns somewhere between 0 and 25 results, unpredictably.

The real fix isn't a smarter pagination strategy, it's removing the FilterExpression entirely. Design a GSI keyed on the attribute you're filtering by (here, status, or a multi-attribute GSI with status in the partition key). DynamoDB then reads only the matching records directly, Limit caps what you actually want, and pagination behaves predictably.

Final Thoughts & Conclusion

DynamoDB rewards you for designing around your access patterns up front, and punishes you for pretending it's SQL. The two biggest shifts from a relational mindset are:

1. Queries are the schema. You model tables, keys, and GSIs around the queries you need to run. You don't normalise and figure out queries later.

2. Keys do the work. The Query operation is fast and cheap precisely because it uses the partition key to jump straight to the right data. Scans read everything, and they get worse as your data grows.

The November 2025 multi-attribute GSI release is a genuinely welcome change, and is a huge improvement to the AWS resource. It removes one of the most painful ergonomic issues with DynamoDB, synthetic key construction and backfilling, without loosening the constraints that make DynamoDB fast.

The query rules (all partition-key attributes supplied, sort-key attributes queried left-to-right) stay exactly the same. What you gain is cleaner, typed, natural data models and the ability to add new access patterns to existing tables without a data migration.

For new projects, my recommendation is to use multi-attribute GSIs by default. For existing codebases built on synthetic keys, evaluate whether a migration makes sense, the painful part of such migrations is now gone.

As always if you want to discuss this further, or hear about my other articles drop me a follow on 'X'.

This approach ensures consistent, reliable releases across multiple environments while supporting best practices like infrastructure as code, security scanning, and observability. It can help your organization deliver cloud-ready .NET software efficiently and safely.

In this article, you'll learn how to implement cloud-native CI/CD pipelines for enterprise .NET applications using Azure DevOps, Docker, and Kubernetes.

Table of Contents

• Prerequisites

• Overview

• Principles of Cloud-Native .NET Development

• Understanding Azure DevOps CI/CD Pipelines

• Creating an Azure DevOps Pipeline for a .NET Application

• Containerizing .NET Applications

• Building and Publishing Docker Images in Azure DevOps

• Deploying to Azure Kubernetes Service (AKS)

• Managing Environments with Deployment Stages

• Infrastructure as Code with Azure DevOps

• Implementing Security in CI/CD Pipelines

• Observability and Monitoring

• Best Practices for Enterprise CI/CD Pipelines

• Conclusion

Prerequisites

Before moving into cloud-native development with Azure DevOps CI/CD pipelines, it’s helpful to have a basic understanding of the following concepts:

• Familiarity with building applications using ASP.NET Core or .NET (for example, controllers, APIs, project structure).

• Understanding how to clone repositories, create branches, and push code changes.

• Ability to run commands such as dotnet build, docker build, and kubectl.

• Understanding what Continuous Integration and Continuous Deployment mean and why they're important.

• Basic idea of how containerization works and how Docker packages applications.

• Familiarity with Microsoft Azure or similar cloud providers.

To work through the examples, you should also have the following tools:

• .NET SDK (version 6 or later recommended)

• Docker installed locally

• Azure DevOps account

• Azure CLI (optional but useful)

• A code editor like VS Code or Visual Studio

Overview

Modern enterprise applications must be built to scale, adapt, and deploy quickly. Traditional monolithic deployment strategies (where applications are manually built, tested, and deployed) are no longer sufficient for teams delivering software in fast-paced environments. Organizations now expect rapid feature delivery, automated testing, and resilient infrastructure.

Cloud-native development addresses these challenges by embracing automation, microservices architectures, containerization, and continuous delivery. For .NET teams building enterprise applications, combining cloud-native principles with Azure DevOps CI/CD pipelines provides a powerful way to automate software delivery and improve reliability.

Azure DevOps enables teams to create fully automated pipelines that build, test, and deploy applications across environments. When integrated with .NET applications and cloud platforms such as Azure Kubernetes Service (AKS) or Azure App Service, CI/CD pipelines become the backbone of cloud-native development workflows.

By the end of this guide, you will understand how to implement a cloud-native delivery pipeline for .NET applications using Azure DevOps.

Principles of Cloud-Native .NET Development

Cloud-native applications are designed specifically to run in dynamic cloud environments. Rather than treating the cloud as simply another hosting location, cloud-native systems take advantage of elasticity, automation, and distributed architecture.

Key principles include:

Microservices Architecture

Modern .NET applications are often split into smaller independent services. Each microservice can be deployed, scaled, and updated independently. This reduces system coupling and allows teams to deploy features faster.

Stateless services

Cloud-native services typically avoid storing session data locally. Instead, state is stored in distributed databases, caches, or storage services. This allows applications to scale horizontally across multiple instances.

Containerization

Containers package applications along with their dependencies, ensuring consistent execution across environments. Technologies like Docker allow .NET services to run identically in development, testing, and production.

Infrastructure as Code

Cloud infrastructure is defined declaratively using templates such as Bicep, ARM, or Terraform. This ensures environments are reproducible, version-controlled, and automated.

Observability and Resilience

Cloud-native applications must be observable through logs, metrics, and traces. They also require resilience patterns such as retries, circuit breakers, and health checks.

Azure DevOps pipelines help enforce these principles by automating builds, deployments, and operational processes.

Understanding Azure DevOps CI/CD Pipelines

Azure DevOps pipelines automate the process of building, testing, and deploying applications.

A typical pipeline consists of two stages:

• Continuous Integration (CI)

• Continuous Deployment (CD)

Continuous Integration (CI)

Continuous Integration ensures that every code change is automatically built and tested.

When developers push code to the repository, the pipeline:

• Restores dependencies

• Compiles the application

• Runs automated tests

• Produces build artifacts

This process helps teams detect issues early and maintain code quality.

Continuous Deployment (CD)

Continuous Deployment takes the build artifacts and deploys them to different environments, such as:

• Development

• Staging

• Production

Deployment can include infrastructure provisioning, container image publishing, and application rollout.

Creating an Azure DevOps Pipeline for a .NET Application

Azure DevOps uses YAML pipelines to define automation workflows.

Let’s start with a simple pipeline configuration for building a .NET application.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '8.0.x'

- script: dotnet restore
  displayName: Restore dependencies

- script: dotnet build --configuration $(buildConfiguration)
  displayName: Build project

- script: dotnet test --configuration $(buildConfiguration)
  displayName: Run unit tests

- script: dotnet publish -c \((buildConfiguration) -o \)(Build.ArtifactStagingDirectory)
  displayName: Publish application

- task: PublishBuildArtifacts@1

 inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: drop

This pipeline performs the following tasks:

1. Installs the .NET SDK

2. Restores NuGet dependencies

3. Builds the application

4. Runs tests

5. Publishes build artifacts

Once the artifacts are generated, they can be deployed automatically.

Containerizing .NET Applications

Cloud-native systems commonly use containers to ensure consistency across environments.

Docker allows you to package your .NET application and its dependencies into a container image.

Here is an example Dockerfile for an ASP.NET Core application:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .

ENTRYPOINT ["dotnet", "MyApp.dll"]

This Dockerfile uses a multi-stage build to keep the final container image lightweight.

The application is compiled in the build stage and then copied into a smaller runtime image.

Building and Publishing Docker Images in Azure DevOps

After containerizing your application, the pipeline can automatically build and push the container image.

- task: Docker@2
  displayName: Build and push Docker image
  inputs:
    command: buildAndPush
    repository: myregistry.azurecr.io/myapp
    dockerfile: Dockerfile
    containerRegistry: MyAzureContainerRegistry
    tags: |
      $(Build.BuildId)
      latest

This step performs two important actions:

1. Builds the Docker image

2. Pushes it to Azure Container Registry (ACR)

Once stored in ACR, the image can be deployed to various environments.

Deploying to Azure Kubernetes Service (AKS)

Kubernetes is a popular orchestration platform for cloud-native applications.

Azure Kubernetes Service (AKS) simplifies Kubernetes deployment and management.

To deploy the application, you can use a Kubernetes deployment manifest.

Example deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dotnet-app
template:
    metadata:
      labels:
        app: dotnet-app
spec:
      containers:
      - name: dotnet-app
        image: myregistry.azurecr.io/myapp:latest
        ports:
        - containerPort: 80

This configuration defines:

• A deployment with three replicas

• The container image to run

• The exposed port

Now we add a pipeline step to deploy it.

- task: KubernetesManifest@0
  inputs:
    action: deploy
    kubernetesServiceConnection: myKubernetesConnection
    namespace: default
    manifests: deployment.yaml

This step updates the Kubernetes cluster with the latest version of the application.

Managing Environments with Deployment Stages

Enterprise pipelines often include multiple environments.

For example:

• Development

• QA

• Production.

Azure DevOps allows pipelines to define deployment stages.

Example:

stages:
- stage: Build
 jobs:
  - job: BuildApp
  steps:
      - script: dotnet build

  - stage: DeployDev
  dependsOn: Build
  jobs:
  - deployment: DeployDev
    environment: dev
    strategy:
     runOnce:
       deploy:
        steps:
          - script: echo Deploying to Dev
- stage: DeployProd
  dependsOn: DeployDev
  jobs:
  - deployment: DeployProd
    environment: production

Stages allow teams to:

• Approve deployments

• Run environment-specific tests

• Control promotion between environments

Infrastructure as Code with Azure DevOps

Cloud-native environments require automated infrastructure provisioning.

Tools such as Terraform, Bicep, or ARM templates allow infrastructure to be defined as code.

Example Terraform pipeline step:

- script: |
    terraform init
    terraform plan
    terraform apply -auto-approve
  displayName: Provision infrastructure

This ensures infrastructure environments remain consistent and reproducible.

Implementing Security in CI/CD Pipelines

Security in CI/CD pipelines should be automated and enforced at every stage of the delivery lifecycle. Instead of treating security as a separate step, modern pipelines integrate security checks directly into build and deployment workflows.

Below are practical implementations of key security practices.

1. Secure Secrets with Azure Key Vault

Never hardcode secrets such as API keys, connection strings, or credentials in your codebase.

In Azure DevOps, you can link secrets from Azure Key Vault using variable groups.

Pipeline Example

variables:
- group: KeyVault-Secrets

Usage in Code

var connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION");

This ensures:

• Secrets are stored securely

• No sensitive data is exposed in source control

• Secrets can be rotated without code changes

2. Dependency Vulnerability Scanning

Automatically scan for vulnerable packages during the build process.

Pipeline Step:

- script: dotnet list package --vulnerable
  displayName: Check for vulnerable dependencies

Example Output (What You’ll See)

This allows teams to:

• Detect vulnerabilities early

• Prevent insecure builds from progressing

3. Static Code Analysis

Use tools like SonarCloud or built-in analyzers to catch security issues.

Example Pipeline Step:

- task: SonarCloudAnalyze@1

This can detect:

• SQL injection risks

• Hardcoded credentials

• Unsafe API usage

4. Enforcing Secure Build Policies

You can enforce rules such as:

• Blocking builds with vulnerabilities

• Requiring pull request approvals

Example – Fail Pipeline on Vulnerabilities:

- script: |
    dotnet list package --vulnerable | grep "High" && exit 1 || echo "No        high vulnerabilities"
  displayName: Fail on high vulnerabilities

5. Container Security Scanning

Scan Docker images before deployment.

- task: Docker@2
  displayName: Scan Docker Image
  inputs:
    command: build

You can integrate tools like Trivy or Microsoft Defender for Containers.

Observability and Monitoring

Cloud-native applications require strong observability.

Observability ensures that you can understand how your application behaves in production. In cloud-native systems, it is essential for debugging, performance optimization, and reliability.

A complete observability strategy includes:

• Logs

• Metrics

• Traces

1. Adding Application Insights to a .NET App

Azure Application Insights provides built-in telemetry for .NET applications.

Setup in ASP.NET Core:

builder.Services.AddApplicationInsightsTelemetry();

Example: Custom Logging

private readonly ILogger<HomeController> _logger;

public HomeController(ILogger<HomeController> logger)
{
    _logger = logger;
}

public IActionResult Index()
{
    _logger.LogInformation("Home page accessed");
    return View();
}

In Azure Portal, this appears as:

• Request logs

• Response times

• Dependency tracking

2. Tracking Custom Metrics

You can track business-specific metrics.

var telemetryClient = new TelemetryClient();

telemetryClient.TrackMetric("OrdersProcessed", 1);

Example use cases:

• Number of API calls

• Orders processed

• Failed transactions

3. Distributed Tracing Example

Tracing helps track requests across services.

using System.Diagnostics;

var activity = new Activity("ProcessOrder");
activity.Start();

// Business logic here

activity.Stop();

This allows you to:

• Trace request flow across microservices

• Identify bottlenecks

4. Observability in CI/CD Pipelines

You can also monitor pipeline execution itself.

Example: Logging in Pipeline

- script: echo "Deploying version $(Build.BuildId)"
  displayName: Log deployment version

Example: Tracking Deployment Time

- script: date
  displayName: Start Time

- script: echo "Deploying..."

- script: date
  displayName: End Time

5. Monitoring Kubernetes Deployments

If using AKS, monitor pods and services.

kubectl get pods
kubectl logs <pod-name>

This helps identify:

• Crashes

• Restart loops

• Performance issues

• What Observability Looks Like in Practice

In a real system, observability enables you to answer questions like

• Why is this request slow?

• Which service failed?

• What changed in the last deployment?

For example:

A spike in latency can be traced to a slow database query. Increased errors can be linked to a recent deployment. And high CPU usage can be caused by inefficient code.

Best Practices for Enterprise CI/CD Pipelines

Designing CI/CD pipelines for enterprise .NET applications requires more than automation—it requires consistency, reliability, and control. Below are key best practices with real examples to show how they are implemented in practice.

1. Keep Pipelines Declarative (YAML-Based)

Defining pipelines in YAML ensures they are version-controlled and reproducible.

Example:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: dotnet build

This approach allows you to:

• Track pipeline changes in Git

• Review pipeline updates via pull requests

• Reuse templates across projects

2. Implement Automated Testing at Multiple Levels

A robust pipeline includes unit, integration, and end-to-end tests.

Example:

- script: dotnet test --filter Category=Unit
  displayName: Run Unit Tests

- script: dotnet test --filter Category=Integration
  displayName: Run Integration Tests

This ensures that bugs are caught early, critical workflows are validated, and releases are more stable.

3. Use Immutable Build Artifacts

Build once and deploy the same artifact across all environments.

Example:

- script: dotnet publish -c Release -o $(Build.ArtifactStagingDirectory)

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: drop

Deployment Uses Same Artifact

- task: DownloadBuildArtifacts@0
  inputs:
    artifactName: drop

This prevents environment inconsistencies and “Works on my machine” issues.

4. Enable Safe Deployment Strategies (Blue-Green / Canary)

Avoid deploying directly to all users at once.

Example: Canary Deployment Concept

- script: echo "Deploying to 10% of users"

In Kubernetes:

spec:
  replicas: 10

Then gradually increase replicas of the new version.

This allows:

• Gradual rollout

• Early detection of failures

• Quick rollback if needed

5. Enforce Pull Request Validation

Ensure code is tested before merging into main branches.

Example:

pr:
- main
steps:
- script: dotnet build
- script: dotnet test

This ensures that only validated code is merged, and that code quality remains high.

6. Use Environment Approvals for Production

Prevent accidental deployments to production.

Example:

- stage: DeployProd
  jobs:
- deployment: Deploy
    environment: production

Azure DevOps allows manual approvals and role-based access control.

This ensures that you have controlled releases and results in reduced risk.

7. Version Your Builds and Artifacts

Every build should be uniquely identifiable.

Example:

- script: echo "Version: $(Build.BuildId)"

For Docker:

tags: |
  $(Build.BuildId)
  latest

This allows for easy rollbacks and traceability.

8. Add Logging and Diagnostics in Pipelines

Pipelines should produce meaningful logs.

Example:

- script: echo "Starting deployment..."
- script: dotnet build
- script: echo "Build completed"

This helps you debug failed pipelines and understand execution flow.

9. Automate Infrastructure Provisioning

Don't manually create infrastructure. Instead, use a tool like Terraform.

Example (Terraform):

- script: |
    terraform init
    terraform apply -auto-approve

This ensures consistent environments and repeatable deployments.

10. Monitor Pipeline and Deployment Performance

Track metrics such as build time and deployment frequency.

Example:

- script: echo "Build completed at $(date)"

You can track:

• Build duration

• Deployment success rate

• Failure trends

Conclusion

Cloud-native development has transformed how enterprise .NET applications are built and delivered. By adopting containerization, automated pipelines, and infrastructure as code, teams can deliver reliable software faster and with greater confidence.

Azure DevOps CI/CD pipelines play a central role in this process. They automate everything from building and testing applications to packaging containers and deploying them across cloud environments. When combined with technologies such as Docker, Kubernetes, and Azure monitoring services, they enable .NET teams to build scalable, resilient, and continuously deployable systems.

For teams beginning their cloud-native journey, the best starting point is to automate the build and test process using CI pipelines. From there, gradually introduce containerization, deployment automation, and infrastructure as code. As pipelines mature, organizations can incorporate advanced practices such as multi-environment deployments, automated security scanning, and progressive rollout strategies.

Ultimately, cloud-native CI/CD pipelines turn software delivery into a repeatable and reliable process. For enterprise .NET applications, this shift allows development teams to focus less on manual operations and more on delivering value through faster innovation and continuous improvement.

But we rarely talk about the downsides of microservices. In medium to large-scale systems, the number of services can grow quickly. Netflix reportedly runs over seven hundred microservices, and Uber manages more than two thousand. That kind of scale introduces a lot of moving parts, testing complexity, and debugging challenges across service boundaries. And all of this can severely impact developer experience (DX).

Recently, I came across a new framework called .NET Aspire, which dramatically simplifies local microservices development. Aspire handles service discovery, configuration management, and observability for distributed applications, giving you a complete view of your system through a built-in dashboard. This results in a much simpler, smoother local development experience compared to manually wiring up multiple services. In this guide, we'll explore how Aspire works and how it can help improve developer experience in microservices-based systems.

Prerequisites

Before we begin, ensure you have the following installed:

• .NET 8 SDK or later

• Docker Desktop

  • Aspire uses Docker to run dependencies like Redis, PostgreSQL, and so on.

  • Ensure Docker is running before starting

• Visual Studio 2022 (v17.9+) or Visual Studio Code with C# Dev Kit

• Basic understanding of:

  • C# and .NET development

  • Microservices architecture concepts

  • REST APIs and service communication

Optional but Recommended:

• Familiarity with Docker and containerization

• Experience with distributed application development

• Knowledge of observability concepts (logging, tracing, metrics)

Table of Contents

• Prerequisites

• Understanding Developer Experience in Microservices

• Introducing .NET Aspire

• How to Set Up .NET Aspire in Your Project

• Why This Matters for Developer Experience

• Framework: How to Adopt .NET Aspire Incrementally

• How to Use the .NET Aspire Dashboard

• Practical Scenarios: Solving Real-World DX Challenges with .NET Aspire

• Going Further

• Key Takeaways and When to Use .NET Aspire

• When (and When Not) to Use .NET Aspire

• Conclusion

Understanding Developer Experience in Microservices

When people talk about DX, they often think of it as tooling or ergonomics, things like good documentation, fast build times, and clean APIs. But in distributed systems, DX becomes much broader. It’s about how easily developers can set up, run, and reason about the systems they’re building.

In a monolithic application, starting your development environment might mean running a single command like dotnet run. But in a microservices-based system, you might need to start multiple APIs, databases, background workers, and queues, all with specific configuration dependencies. This extra overhead doesn’t just slow you down, it breaks your focus and adds friction to daily development.

Over time, that friction compounds.

• Onboarding new developers becomes slower.

• Debugging across service boundaries gets harder.

• Teams spend more time managing environments than writing features.

That’s why DX is so important in microservices architectures. It is not just about developer happiness, it’s about velocity, consistency, and confidence. If your local environment isn’t easy to run or reason about, every other process in your development lifecycle suffers.

This is where orchestration frameworks like .NET Aspire start to make a real difference. They handle the complexity of coordinating services, so developers can focus on building and iterating faster, the way modern software development is meant to work.

Introducing .NET Aspire

As microservice systems grow, local development environments often become a patchwork of scripts, Docker Compose files, and manual setup steps. Each developer ends up managing their own version of “how to get things running,” and small differences in configuration can lead to big inconsistencies across teams.

.NET Aspire is an orchestration framework designed to simplify this process. It provides a way to define, configure, and run your distributed applications as a single unit, directly within your .NET solution.

In practical terms, Aspire helps developers by handling three key areas automatically:

1. Service Orchestration
   Aspire can start multiple projects (APIs, workers, databases, and so on) in the correct order. It takes care of service dependencies so that, for example, your API doesn’t try to start before the database it depends on is ready.

2. Configuration Management
   Instead of juggling dozens of appsettings.json files or environment variables, Aspire provides a centralized configuration model. It shares connection strings, ports, and environment settings across services in a consistent way.

3. Observability and Insights
   Aspire includes built-in OpenTelemetry support and a dashboard that gives you real-time visibility into your running services, including their health, logs, and endpoints. This makes debugging and local monitoring much easier.

In many ways, Aspire does for services what Kubernetes does for containers, but with a sharper focus on local development and developer experience. It’s not meant to replace your production orchestration tools, it’s designed to make your everyday development smoother, faster, and less error-prone.

How to Set Up .NET Aspire in Your Project

We'll create a microservices setup and watch Aspire orchestrate it with minimal code. Make sure you're running .NET 8 or later. Aspire requires it.

Create a New Aspire Project

Start by creating a new Aspire app host using the .NET CLI:

dotnet new aspire-app -n MyCompany.AppHost

This command creates a new Aspire “host” project, the entry point that orchestrates your other microservices, APIs, and dependencies.

You’ll notice that the generated project contains a Program.cs file with an AppHostBuilder. This builder acts as the control center for your distributed system.

Add Your Microservices

You can now reference your existing projects or create new ones directly in the same solution. For example:

dotnet new webapi -n CatalogService
dotnet new webapi -n OrderService
dotnet new worker -n NotificationWorker

Then, add them to your Aspire host by editing Program.cs:

var builder = DistributedApplication.CreateBuilder(args);

var catalog = builder.AddProject<Projects.CatalogService>("catalog");
var order = builder.AddProject<Projects.OrderService>("order")
                   .WaitFor(catalog); // ensure this starts after CatalogService
var notifications = builder.AddProject<Projects.NotificationWorker>("notifications");

builder.Build().Run();

In this example:

• AddProject registers each service with Aspire.

• .WaitFor() enforces startup dependencies (for example, OrderService depends on CatalogService).

• Aspire takes care of starting these services in the right order, sharing environment variables, and managing ports automatically.

Run All Services with One Command

Now, from your app host directory, run:

dotnet run

Aspire will:

• Start all the registered services.

• Allocate available ports.

• Inject shared configurations.

• Launch a local dashboard showing service health, endpoints, and logs.

You should see output like this:

Starting CatalogService...
Starting OrderService...
Starting NotificationWorker...
AppHost running on http://localhost:18888

And when you open the dashboard in your browser, you’ll see all your services, their statuses, and links to their APIs.

Add a Local Database (Optional)

To show how Aspire handles dependencies, let’s add a PostgreSQL container:

var db = builder.AddPostgres("postgres");
builder.AddProject<Projects.CatalogService>("catalog")
       .WithReference(db); // injects connection string automatically

Now when you run the app, Aspire will start PostgreSQL first, generate a connection string, and pass it to CatalogService. No manual setup or .env files required.

Why This Matters for Developer Experience

Before Aspire, getting your local environment running meant opening multiple terminals, waiting around for databases to start, and copying connection strings between projects. With Aspire, it's just one command. Everything starts automatically, configuration is shared across services, and you get observability built in. That's the developer experience win. Less time fighting your setup, more time actually coding.

Framework: How to Adopt .NET Aspire Incrementally

If you’re considering trying Aspire in your own team, you don’t have to migrate everything at once. In fact, the best approach is incremental adoption. Start small and expand gradually.

Here’s a simple framework you can follow:

Step 1: Start Small

Create an Aspire host and connect one or two key services.
This helps your team understand the orchestration flow before scaling up.

dotnet new aspire-app -n MyCompany.AppHost

Step 2: Add Dependencies Incrementally

As you grow, include more services and use .WaitFor() to define dependencies and startup order.

var builder = DistributedApplication.CreateBuilder(args);

var db = builder.AddPostgres("postgres");
builder.AddProject<Projects.CatalogService>("catalog")
       .WithReference(db);
builder.AddProject<Projects.ApiGateway>("gateway")
       .WaitFor("catalog");

builder.Build().Run();

Step 3: Integrate Observability

Leverage Aspire’s built-in OpenTelemetry integration for metrics and traces. You’ll instantly gain better insight into service interactions even without external tools.

Step 4: Share Your Setup

Commit your Aspire host to source control so every developer uses the same setup.
This ensures consistency across environments, reducing the classic “works on my machine” problem.

Note: Aspire doesn’t require a full rewrite. It works great as a starting layer while your team continues evolving your existing orchestration setup.

How to Use the .NET Aspire Dashboard

One of the standout features of .NET Aspire is its built-in dashboard, which gives you real-time visibility into your microservices while they run locally.

When you start your Aspire app host with dotnet run, it automatically spins up a local dashboard (by default at http://localhost:18888). This dashboard provides a centralized view of all your services — APIs, databases, background workers, and any connected dependencies.

Here’s what you’ll find inside:

Service Overview

The dashboard home page lists every service in your distributed application. For each one, you can see:

• Name and type (for example, cache, apiservice, webfrontend)

• Current state (Running, Starting, Stopped)

• Source

• Port and endpoint information

• Startup time and uptime

• Logs and metrics shortcuts

This immediately replaces the need to track multiple terminal windows or scroll through dozens of logs just to confirm everything started correctly.

The dashboard automatically detects unhealthy or failed services and highlights them, so you can identify startup issues early.

Navigating to Endpoints

Each service card includes quick links to its exposed endpoint, providing easy access to relevant tools and interfaces. For example, APIs may include links to Swagger UI or Scalar, databases may link to pgAdmin or similar management tools, and internal services may offer links to custom dashboards.

This setup allows users to test APIs or verify database connections directly from the dashboard without needing to remember specific ports or manually construct URLs.

Real-Time Logs

Clicking into a specific service opens a detailed view showing real-time logs streamed directly from that service.

This is especially helpful when debugging startup issues or service interactions. Instead of running dotnet run in separate terminals, you can view logs for all your services in one place, color-coded and timestamped for clarity.

Observability Built-In (OpenTelemetry)

Aspire includes OpenTelemetry by default, which means that even without additional configuration, you automatically gain access to several powerful observability features. These include distributed traces across service boundaries, metrics for performance monitoring, and correlated logs that help track requests spanning multiple services.

For teams already using tools like Grafana, Jaeger, or SigNoz, Aspire can export this telemetry data to your preferred observability platform with minimal setup.

With tracing enabled, you can follow a request as it travels from your API to your database, through background workers, and back, all from within the dashboard.

Why the Dashboard Improves Developer Experience

Without Aspire, running a local microservices environment typically requires managing multiple terminal windows, tracking ports manually, and searching through log files to diagnose failures.

Aspire consolidates these tasks into a single visual interface where developers can view all services, check dependencies, inspect logs, and monitor system health directly from the browser.

This integrated environment enables faster debugging, maintains developer focus, and simplifies work with complex systems by reducing the overhead of manual coordination.

Practical Scenarios: Solving Real-World DX Challenges with .NET Aspire

So far, we have looked at how Aspire works and what it provides out of the box. But to really understand its impact on developer experience, let’s go through a few real-world pain points that almost every team building with microservices has faced, and how Aspire helps solve them.

Starting Multiple Services in the Right Order

The Problem: In most microservices setups, service startup order matters. For instance, your API Gateway might depend on the User Service and Catalog Service, which both depend on a Database.
If you start these in the wrong order, the gateway fails to connect, and you end up restarting services manually until everything stabilizes.

How Aspire Solves It: Aspire provides a simple way to express dependencies using .WaitFor():

var builder = DistributedApplication.CreateBuilder(args);

var db = builder.AddPostgres("postgres");
var user = builder.AddProject<Projects.UserService>("user")
                  .WithReference(db);

var catalog = builder.AddProject<Projects.CatalogService>("catalog")
                     .WithReference(db);

var gateway = builder.AddProject<Projects.ApiGateway>("gateway")
                     .WaitFor(user)
                     .WaitFor(catalog);

builder.Build().Run();

Aspire automatically ensures that each service only starts after the services it depends on are fully ready.
No more manual sequencing or “start this one first” instructions in your README.

Port Conflicts and Configuration Drift

The Problem: Developers often encounter the dreaded “Port 5000 is already in use” or spend time editing configuration files to avoid conflicts. Over time, local setups diverge across the team, making onboarding and debugging harder.

How Aspire Solves It: Aspire dynamically manages ports and configuration at runtime. Each service gets a unique port assignment, and Aspire automatically shares connection information across services.

You can still set explicit ports when needed:

builder.AddProject<Projects.Frontend>("frontend")
       .WithHttpEndpoint(port: 5173);

This removes guesswork, keeps environments consistent, and ensures new developers can clone the repo and start everything without editing config files.

Simplifying New Developer Onboarding

The Problem: For many teams, onboarding means following a long README with dozens of setup steps, manual database migrations, and environment variable configurations. It can take hours, or even days before a new developer can run the system locally.

How Aspire Solves It: Aspire defines your entire environment in code. That means the setup process becomes as simple as cloning the repository and running one command:

dotnet run

Aspire will start all necessary services, configure dependencies, and bring up the dashboard for visibility. This transforms onboarding from a multi-hour process into something that can be completed in minutes, with far fewer setup issues.

Improving Debugging and Cross-Service Visibility

The Problem: Debugging in microservices often means jumping between logs, tracing requests across multiple services, or reproducing issues that only appear when several services run together.

How Aspire Solves It: With built-in observability and the Aspire dashboard, you can view logs across all services in one place, inspect health checks and metrics, and trace requests using OpenTelemetry. This makes it much easier to identify issues across service boundaries and speeds up debugging, especially during integration testing or local development.

Running Optional or External Services

The Problem: Sometimes you don’t need to run every service locally. For example, you might connect to a shared staging API or external dependency instead of running a local instance.

How Aspire Solves It: Aspire lets you make services optional using conditional checks:

if (Directory.Exists("../Frontend"))
{
    builder.AddProject<Projects.Frontend>("frontend");
}

This makes your setup flexible: you can run a minimal environment for development or a full environment for integration testing, all using the same configuration.

Why These Scenarios Matter

Each of these examples solves a specific friction point in the developer experience. Startup complexity, environment drift, onboarding time, and debugging difficulty.

By automating orchestration and configuration, Aspire frees developers from repetitive setup work and lets them focus on building features instead of managing infrastructure.

Going Further

Once you’re comfortable with Aspire’s basics, you can extend it beyond local orchestration to streamline other parts of your workflow.

• Integrate front-end applications
  Orchestrate React, Angular, or Node.js apps alongside your .NET services for a unified full-stack setup.

• Export telemetry data
  Send Aspire’s OpenTelemetry output to platforms like Grafana, Jaeger, or Azure Application Insights for deeper analysis.

• Use Aspire in CI/CD pipelines
  Bring up full environments for integration or smoke testing during continuous integration runs, all using your existing Aspire configuration.

• Explore community examples
  Check out the official Aspire samples and templates for advanced orchestration patterns, cloud integration, and observability setups.

Key Takeaways and When to Use .NET Aspire

As we’ve seen throughout this guide, .NET Aspire isn’t just another developer tool, it’s a framework built specifically to improve developer experience in microservices-based applications.

By orchestrating all your services in a consistent, declarative way, Aspire helps teams reduce friction, speed up setup, and make local environments more reliable and observable.

Key Takeaways

1. Developer Experience (DX) matters as your system grows.
   Microservices introduce flexibility and scalability, but they also add complexity; multiple services, ports, dependencies, and startup sequences. Without good orchestration, DX quickly degrades.

2. Aspire simplifies orchestration for local development.
   It automatically handles service startup, dependencies, configuration sharing, and observability all defined in code, right within your .NET solution.

3. The Aspire dashboard improves visibility.
   You get a centralized, real-time view of your entire system; services, logs, health, and endpoints eliminating the need for multiple terminals or manual tracking.

4. Onboarding new developers becomes faster and smoother.
   A single dotnet run command can spin up your entire development environment, reducing setup time from hours or days to minutes.

5. Built-in observability means better debugging and confidence.
   With OpenTelemetry integrated out of the box, developers can trace requests, monitor performance, and diagnose issues across services with minimal setup.

When (and When Not) to Use .NET Aspire

Use Aspire when:

Aspire makes sense if you're building .NET microservices and tired of complex local setup. It's especially valuable when your team is dealing with environment drift, slow onboarding, or startup sequences that feel like juggling. If you want one command to spin up your entire system, with observability built in from day one, Aspire is worth trying.

You might not need Aspire when:

Aspire might not be worth it if your current setup already works well. Maybe you're using Kubernetes or Docker Compose locally and everything runs smoothly. Or you're building a monolith or single service that doesn't need orchestration. Or your stack has a lot of non-.NET components that would need custom wiring. If your local development is already simple and stable, don't fix what isn't broken.

In other words:
Aspire shines in the local development and onboarding phase. Helping developers build, test, and iterate on distributed systems with minimal friction.
It’s not meant to replace production orchestrators like Kubernetes but to complement them by improving the developer’s day-to-day workflow.

Conclusion

Developer Experience is often overlooked when teams move to microservices, but it directly impacts productivity, quality, and morale. By using .NET Aspire, you can bring order, visibility, and simplicity back to your local development environment.

If you’re looking to streamline your microservices workflow, give Aspire a try. You’ll spend less time fighting your setup and more time building what actually matters; great software.

Ready to get started? Check out the official .NET Aspire documentation or clone one of the sample projects to see it in action.

If you made it to the end of this tutorial, thanks for reading! You can also connect with me on LinkedIn if you’d like to stay in touch.

We've just published a comprehensive beginner-friendly course on the freeCodeCamp.org YouTube channel, taught by Alen Omeri, that takes you from absolute beginner to confidently building REST APIs in .NET 9. This step-by-step tutorial is specifically designed for those new to ASP.NET Core, covering everything from basic REST concepts to implementing full CRUD operations with SQL Server database integration.

Foundation and Core Concepts

The course begins with essential theoretical knowledge, explaining what REST APIs are and why they're crucial in modern software development. You'll understand the principles behind RESTful architecture and how APIs enable different applications to communicate effectively. This foundation ensures you're not just copying code, but truly understanding the concepts behind what you're building.

From there, you'll dive into getting started with ASP.NET Core, learning the framework's structure and how it facilitates API development. The tutorial covers REST API models, teaching you how to design and structure your data representations properly. You'll then progress to creating controllers, the components that handle incoming requests and coordinate responses.

Practical Implementation

The hands-on portion begins with creating lists and working with data, giving you immediate practical experience with API functionality. You'll explore HTTP methods in detail, understanding how GET, POST, PUT, and DELETE operations work within the REST framework and how to implement each one effectively in your ASP.NET Core application.

Database integration forms a crucial part of the course. You'll learn to install and configure SQL Server and SQL Server Management Studio (SSMS), essential tools for professional API development. The tutorial guides you through creating a database from scratch and establishing the connection between your API project and the database, skills that are fundamental for real-world applications.

Advanced Database Operations

The course covers data seeding techniques, showing you how to populate your database with initial data for testing and development purposes. This practical skill ensures your APIs have realistic data to work with during development and testing phases.

The culmination of the course focuses on implementing complete CRUD operations. You'll build Create, Read, Update, and Delete functionality that connects your API endpoints to actual database operations. This section ties together everything you've learned, demonstrating how to build a fully functional API that can handle real-world data management tasks.

Why This Course Matters

REST APIs are the foundation of virtually every modern web application, mobile app, and cloud service. Learning to build them properly with .NET 9 and ASP.NET Core gives you access to Microsoft's robust, enterprise-grade development ecosystem. The skills you'll gain are directly applicable to professional software development roles and provide a solid foundation for more advanced topics like microservices architecture and cloud deployment.

The course's beginner-friendly approach ensures that even those with no prior API development experience can follow along and build confidence. By the end, you'll have created a complete, database-connected REST API and understand the principles needed to build more complex systems.

Ready to begin your journey into professional API development? Watch the full course on the freeCodeCamp.org YouTube channel (1-hour watch).

Different types of classes serve various purposes. For instance, organizing your logic to make your code easier to navigate is helpful when building an application.

You can group or separate your code into classes, and through inheritance, you can utilize different classes as needed. Classes help encapsulate your code, enabling you to reuse your logic in other application parts. Classes have many functionalities, and we will explore some of them in detail.

In this guide, we'll explore various types of classes in C# and how you can use them to create efficient and maintainable code.

Prerequisites

Before we proceed, you should have the following:

1. Basic knowledge of C#: you should understand C# syntax and basic programming constructs like variables, loops, and conditionals.

2. Familiarity with Object-Oriented Programming (OOP) concepts: you should know how to work with classes, objects, inheritance, polymorphism, encapsulation, and abstraction.

3. Familiarity with access modifiers: you should understand public, private, internal, and protected access modifiers.

4. Experience with C# IDE/Environment: you should be able to write and run C# programs using an IDE like Visual Studio.

If you want to learn more about C#, you can check out my YouTube channel: CliffTech.

Table of Contents

• Static Classes in C Sharp

• Sealed Classes in C Sharp

• Concrete Classes in C Sharp

• Abstract Classes in C Sharp

• Singleton Classes in C Sharp

• Generic Classes in C Sharp

• Internal Classes in C Sharp

• Nested Classes in C Sharp

• Partial Classes in C Sharp

• Conclusion

The first type of class we’ll discuss is the Static Class. Let’s dive in.

Static Classes in C Sharp

Static classes are a special type of class in C# designed to provide a collection of related utility methods and properties that do not rely on instance data.

Static classes in C# are a unique type of class designed to house a collection of related utility methods and properties that don't depend on instance data.

Unlike regular classes, static classes cannot be instantiated, and they exclusively contain static members. This characteristic means they cannot be inherited, making them perfect for organizing stateless methods that don't require the features of object-oriented programming.

In essence, when we refer to stateless grouping, it implies that there's no need to create an instance to call a static method – you can simply use the class or method name directly. This approach provides a clear and efficient way to manage utility functions, enhancing code organization and accessibility.

Example of a Static Class in C

Here's an example of a static class in C#:

namespace StaticClasses
{
// Define a static class
    public static class MathUtils
    {
        // Static method to add two numbers
        public static int Add(int a, int b)
        {
            return a + b;
        }

        // Static method to subtract two numbers
        public static int Subtract(int a, int b)
        {
            return a - b;
        }

       // Static method to multiply two numbers
        public static int Multiply(int a, int b)
        {
            return a * b;
        }
    }
}

In this example:

• The MathUtils class is defined as static, meaning it cannot be instantiated.

• It contains three static methods: Add, Subtract, and Multiply.

• These methods can be called directly on the MathUtils class without creating an instance.

Before you can use this, you need to call it in your Program.cs. When you create any C# application, the entry point is Program.cs. You’ll need to go there and make sure to call these classes so that you can execute them. This is what we will be doing for the rest of the section.

How to Use Static Methods in Program.cs

Now you can use the static methods defined in the MathUtils class as follows:

 // program.cs
namespace StaticClasses
{
    class Program
    {
        static void Main(string[] args)
        {
             // Call static methods from the MathUtils class
            int sum = MathUtils.Add(5, 3);
            // Call the static method Subtract from the MathUtils class
            int difference = MathUtils.Subtract(5, 3);

            // Call the static method Multiply from the MathUtils class
            int product = MathUtils.Multiply(5, 3);

            // Display the results of the sum method
            Console.WriteLine($"Sum: {sum}"); // Output: 8
            // Display the results of the difference method
            Console.WriteLine($"Difference: {difference}"); // Output: 2
            // Display the results of the product method
            Console.WriteLine($"Product: {product}");  // Output: 15
        }
    }
}

When to Use Statice Classes vs Methods

To decide when to use static classes or methods in C#, consider the following guidelines:

1. Use Static Classes when:

   • You need a collection of utility or helper methods that do not require any instance data.

   • The methods and properties are stateless and can be accessed globally without creating an object.

   • You want to group related functions that are not tied to a specific object state.

   • You need to ensure that the class cannot be instantiated or inherited.

2. Use Static Methods when:

   • You have a class that is mostly instance-based, but you need a few methods that do not depend on instance data.

   • The method performs a task that is independent of any object state and can be executed without an instance.

   • You want to provide a utility function within a class that can be accessed without creating an object of that class.

By using static classes and methods appropriately, you can enhance code organization, improve performance by avoiding unnecessary object creation, and ensure that certain functionalities are easily accessible throughout your application.

Key Points to Remember About Static Classes in C

• Cannot be Instantiated: You cannot create objects from a static class.

• Only static members: Static classes can only have static members. They do not support instance methods or fields.

• Sealed by default: Static classes are automatically sealed, so they cannot be inherited.

• Utility and helper methods: Static classes are usually used to group related utility or helper methods that don't need an object state.

Static classes help organize and access utility methods and properties clearly and simply, making them important for creating efficient and maintainable code.

Sealed Classes in C Sharp

Sealed classes are a special type of class in C# that cannot be inherited. You can use them to prevent other classes from deriving from them, which can be useful for creating immutable types or ensuring that a class's behavior remains unchanged.

By sealing a class, you ensure that it cannot be modified or extended, making it useful for scenarios where you want to provide a specific implementation without allowing further alterations.

Example of a Sealed Class in C

Here's an example of a sealed class in C#:

namespace SealedClasses
{

    // Define an abstract class
    public abstract class Shape
    {
        // Abstract method to calculate the area
        public abstract double CalculateArea();
    }

     // Define a sealed class
    public sealed class Rectangle : Shape
    {

        //  Properties
        public double Width { get; }
        public double Height { get; }

        // Constructor
        public Rectangle(double width, double height)
        {
            Width = width;
            Height = height;
        }

       // Implement the CalculateArea method
        public override double CalculateArea()
        {
            return Width * Height;
        }
    }
}

In this example:

• The Shape class is an abstract base class with an abstract method CalculateArea().

• The Rectangle class inherits from Shape and provides an implementation for CalculateArea().

• The Rectangle class is sealed, which means it cannot be inherited from. This ensures that the class's implementation cannot be modified or extended.

How to Use the Sealed Rectangle Class in the Program.cs

Here's how you can use the Rectangle class in a Program.cs file:

namespace SealedClasses
{
    class Program
    {
        static void Main(string[] args)
        {
            Rectangle rectangle = new Rectangle(5, 3);
            double area = rectangle.CalculateArea();

            Console.WriteLine($"Area of the rectangle: {area}"); // Output: Area of the rectangle: 15
        }
    }
}

In this example, the Rectangle class is sealed to ensure that its behavior cannot be changed through inheritance. This guarantees that the Rectangle class's implementation of CalculateArea() stays the same, which helps maintain consistent behavior.

When to Use Sealed Classes

Sealed classes are particularly useful in the following contexts:

1. Framework development: When developing frameworks or libraries, you might use sealed classes to lock down certain classes that are not intended to be extended by users. This helps maintain control over the framework's behavior and ensures that users cannot introduce bugs or inconsistencies by extending these classes.

2. Preventing inheritance: If a class is designed to be a specific implementation with no need for further customization or extension, sealing it prevents other developers from creating subclasses that might alter its intended functionality.

3. Finalizing class design: When a class has reached a point where its design is considered complete and no further changes or extensions are anticipated, sealing it can signal to other developers that the class should be used as-is.

4. Avoiding overriding: In scenarios where overriding methods could lead to incorrect behavior or security issues, sealing the class ensures that its methods cannot be overridden, preserving the original logic and functionality.

Key Points to Remember About Sealed Classes

• No inheritance: Sealed classes cannot be inherited, ensuring their behavior stays the same.

• Prevent modification: They prevent further inheritance, avoiding accidental changes or extensions.

• Immutable and specific: Sealed classes are useful for creating immutable classes or when you need a specific, unchangeable implementation.

Sealed Classes vs. Static Classes

You might wonder why we need sealed classes if static classes are already sealed. The key differences are:

• Static Classes are sealed and cannot be instantiated. They are used for grouping static methods and properties.

• Sealed Classes can be instantiated but cannot be inherited. This allows for creating objects that are protected from further subclassing.

Sealed classes offer flexibility in creating classes that can be used directly without the risk of modification through inheritance.

Concrete Classes in C Sharp

Concrete classes are essential in object-oriented programming in C#. They are fully implemented classes that you can use to create objects directly.

Unlike abstract classes or interfaces, concrete classes have complete implementations of all their methods and properties, making them versatile and fundamental to most C# applications.

A concrete class is not abstract. It includes full implementations of all its members—methods, properties, fields, and so on—and can be used to create objects. These classes represent real-world entities or concepts in your application, encapsulating both data (stored in fields or properties) and behavior (defined by methods).

Example: Defining a Concrete Class in C

Here's a simple example of a concrete class in C#:

// Define a concrete class
public class Animal
{
    public void Speak()
    {
        Console.WriteLine("The animal makes a sound.");
    }
}

// Define a derived class that inherits from the Animal class
public class Dog : Animal
{
    public void Bark()
    {
        Console.WriteLine("The dog barks.");
    }
}

In this example, the Animal class is a concrete class with a method Speak that represents a generic sound made by any animal. The Dog class inherits from Animal and adds a Bark method to represent a sound specific to dogs. Both Animal and Dog are concrete classes because they can be instantiated and used to create objects.

How to Instantiate and Use Concrete Classes

Here's how you can use the Dog class in a Program.cs file:

// program.cs
class Program
{
    static void Main(string[] args)
    {
        // Create an instance of the Dog class
        Dog myDog = new Dog();

        // Call the inherited method
        myDog.Speak(); // Output: The animal makes a sound.

        // Call the method defined in the Dog class
        myDog.Bark();  // Output: The dog barks.
    }
}

In this example, we create an instance of the Dog class called myDog. We first call the Speak method, which is inherited from the Animal class, and then the Bark method from the Dog class. This shows how concrete classes can include both inherited and unique behaviors.

Real-World Example: Concrete Class for a Product

To illustrate the practical application of concrete classes, consider the following example of a Product class:

// Define a concrete class for a product
public class Product
{
    // Data properties
    public string Name { get; set; }
    public decimal Price { get; set; }

    // Method to display product information
    public void DisplayInfo()
    {
        Console.WriteLine($"Product: {Name}, Price: {Price:C}");
    }
}

This Product class is a concrete class with properties Name and Price to store information about a product. The DisplayInfo method provides a way to display the product’s details.

How to Use the Product Class

Here's how you can use the Product class:

class Program
{
    static void Main(string[] args)
    {
        // Create an instance of the Product class
        Product product = new Product
        {
            Name = "Laptop",
            Price = 1299.99m
        };

        // Display product information
        product.DisplayInfo(); // Output: Product: Laptop, Price: $1,299.99
    }
}

In this scenario, the Product class is used to create a product object. The DisplayInfo method is called to show the product's name and price. This demonstrates how concrete classes are used to model and work with real-world data.

Key Points to Remember About Concrete Classes

• Instantiable: Concrete classes can be instantiated, allowing you to create objects that represent specific entities or concepts in your application.

• Complete implementation: Concrete classes provide full implementations of all methods and properties, unlike abstract classes or interfaces.

• Common use: They are the most common type of class in C#, used to define objects with specific behavior and data.

Concrete classes are essential for C# development, enabling you to define and work with objects that model real-world entities within your applications. Understanding how to effectively use concrete classes is crucial for building robust, object-oriented software.

Abstract Classes in C Sharp

In C#, abstract classes are a powerful feature that allow you to define a blueprint for other classes without providing complete implementations. They serve as base classes that cannot be instantiated directly but can be inherited by other classes that will provide specific implementations for the abstract methods defined within them. This design helps enforce consistency across related classes while allowing flexibility in how certain behaviors are implemented.

What Does "Instantiated" Mean?

Before exploring abstract classes, let's clarify what it means to instantiate a class. Instantiation is the process of creating an object from a class. When you use the new keyword in C#, you are creating an instance (or object) of that class.

But abstract classes cannot be instantiated directly. They must be inherited by a non-abstract (concrete) class that provides implementations for the abstract methods.

Understanding Abstract Classes and Abstract Methods

Abstract classes are classes you can't create objects from directly. They act as templates for other classes. They can have both complete methods and methods without a body (abstract methods). Abstract classes help set up a common interface and shared behavior for related classes.

Abstract methods, on the other hand, are methods in an abstract class that don't have a body. Any non-abstract class that inherits from the abstract class must provide a body for these methods. This ensures all subclasses have a consistent interface.

Real-World Example: Bank Account Management

Let's explore a real-world example to illustrate the concept of abstract classes and abstract methods in C#.

using System;

// define an abstract class
namespace AbstractClasses
{
    // Abstract class
    public abstract class BankAccount
    {
        // Properties
        public string AccountNumber { get; private set; }
        public decimal Balance { get; protected set; }

        // Constructor
        public BankAccount(string accountNumber, decimal initialBalance)
        {
            AccountNumber = accountNumber;
            Balance = initialBalance;
        }

        // Abstract methods
        public abstract void Deposit(decimal amount);
        public abstract void Withdraw(decimal amount);
        public abstract void DisplayAccountInfo();
    }

    // Derived class: SavingsAccount
    public class SavingsAccount : BankAccount
    {
        private decimal interestRate;

        public SavingsAccount(string accountNumber, decimal initialBalance, decimal interestRate)
            : base(accountNumber, initialBalance)
        {
            this.interestRate = interestRate;
        }

        // Implementing abstract methods
        public override void Deposit(decimal amount)
        {
            Balance += amount;
            Console.WriteLine($"Deposited {amount} to Savings Account {AccountNumber}. New Balance: {Balance}");
        }

        public override void Withdraw(decimal amount)
        {
            if (amount > Balance)
            {
                throw new InvalidOperationException("Insufficient funds.");
            }
            Balance -= amount;
            Console.WriteLine($"Withdrew {amount} from Savings Account {AccountNumber}. New Balance: {Balance}");
        }

        public override void DisplayAccountInfo()
        {
            Console.WriteLine($"Savings Account {AccountNumber} - Balance: {Balance}, Interest Rate: {interestRate}%");
        }
    }

    // Derived class: CheckingAccount
    public class CheckingAccount : BankAccount
    {
        private decimal overdraftLimit;

        public CheckingAccount(string accountNumber, decimal initialBalance, decimal overdraftLimit)
            : base(accountNumber, initialBalance)
        {
            this.overdraftLimit = overdraftLimit;
        }

        // Implementing abstract methods
        public override void Deposit(decimal amount)
        {
            Balance += amount;
            Console.WriteLine($"Deposited {amount} to Checking Account {AccountNumber}. New Balance: {Balance}");
        }

        public override void Withdraw(decimal amount)
        {
            if (amount > Balance + overdraftLimit)
            {
                throw new InvalidOperationException("Overdraft limit exceeded.");
            }
            Balance -= amount;
            Console.WriteLine($"Withdrew {amount} from Checking Account {AccountNumber}. New Balance: {Balance}");
        }

        public override void DisplayAccountInfo()
        {
            Console.WriteLine($"Checking Account {AccountNumber} - Balance: {Balance}, Overdraft Limit: {overdraftLimit}");
        }
    }
}

In this example, the BankAccount class is an abstract class that defines a common interface for different types of bank accounts. It includes abstract methods like Deposit, Withdraw, and DisplayAccountInfo, which must be implemented by any class that inherits from BankAccount.

The SavingsAccount and CheckingAccount classes inherit from BankAccount and provide specific implementations for these abstract methods. This design enforces that every type of bank account must implement deposit, withdrawal, and display functions, while still allowing each account type to implement these functions in a way that makes sense for that specific type.

How to Use Abstract Classes in a Program

Let's see how we can use the SavingsAccount and CheckingAccount classes in a Program.cs file.

namespace AbstractClasses
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create a savings account
            BankAccount savings = new SavingsAccount("SA123", 1000, 1.5m);
            // Create a checking account
            BankAccount checking = new CheckingAccount("CA123", 500, 200);

            // Deposit and withdraw from the savings account
            savings.DisplayAccountInfo();

           // Deposit and withdraw from the checking account
            savings.Deposit(200);

            savings.Withdraw(100);
            // Display the updated account information
            savings.DisplayAccountInfo();

            checking.DisplayAccountInfo();

             // Deposit and withdraw from the checking account
            checking.Deposit(300);

            checking.Withdraw(600);

            // Display the updated account information
            checking.DisplayAccountInfo();

            try
            {
                checking.Withdraw(200);
            }
            catch (InvalidOperationException ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }

            checking.DisplayAccountInfo();
        }
    }
}

This program will produce the following output:

Savings Account SA123 - Balance: 1000, Interest Rate: 1.5%
Deposited 200 to Savings Account SA123. New Balance: 1200
Withdrew 100 from Savings Account SA123. New Balance: 1100
Savings Account SA123 - Balance: 1100, Interest Rate: 1.5%
Checking Account CA123 - Balance: 500, Overdraft Limit: 200
Deposited 300 to Checking Account CA123. New Balance: 800
Withdrew 600 from Checking Account CA123. New Balance: 200
Checking Account CA123 - Balance: 200, Overdraft Limit: 200
Withdrew 200 from Checking Account CA123. New Balance: 0
Checking Account CA123 - Balance: 0, Overdraft Limit: 200

In this example, the SavingsAccount and CheckingAccount objects are created, and the abstract methods Deposit, Withdraw, and DisplayAccountInfo are called. The abstract class BankAccount ensures that both account types have these methods, while the derived classes provide the specific functionality.

Key Points to Remember About Abstract Classes

• Cannot be instantiated: You can't create an instance of an abstract class directly. A subclass must inherit it and provide the implementations for the abstract methods.

• Contain abstract methods: Abstract methods in an abstract class have no body. Any non-abstract class that inherits from the abstract class must implement these methods.

• Define common interfaces: Abstract classes set a common interface for related classes, ensuring they are consistent while allowing different implementations.

Abstract classes are important in C#. They help enforce a structure across related classes but still allow for specific details. By using abstract classes, you can make your code more organized, easier to maintain, and extend.

Singleton Classes in C Sharp

Singleton classes are a design pattern that restricts the instantiation of a class to one single instance. This is particularly useful when you need a single, shared resource across your application, such as a configuration manager, logging service, or database connection.

Why Use Singleton Classes in C#?

Imagine you have a class responsible for managing a database connection. You don’t want multiple instances of this class running around, potentially causing issues with resource management or inconsistent data. A Singleton class ensures that only one instance is created and provides a global point of access to it.

Example: Defining a Singleton Class

Let’s now see how you can implement a Singleton class in C#:

// Define a singleton class
public class Singleton
{
    private static Singleton instance;
    private static readonly object lockObject = new object();

    // Private constructor prevents instantiation from outside the class
    private Singleton()
    {
    }

    // Public property to access the single instance of the class
    public static Singleton Instance
    {
        get
        {
            // Ensure thread safety
            lock (lockObject)
            {
                if (instance == null)
                {
                    instance = new Singleton();
                }
            }
            return instance;
        }
    }

    // Example method to demonstrate the singleton instance
    public void PrintMessage()
    {
        Console.WriteLine("Hello, I am a singleton class.");
    }
}

In this example, the Singleton class is defined with a private constructor, which prevents other classes from creating new instances. The static property Instance returns the single instance of the class, creating it if it doesn't already exist. The lockObject ensures that the class is thread-safe, meaning that even in a multi-threaded environment, only one instance will be created.

The PrintMessage method is just a simple example to show that the Singleton instance can be used like any other class instance.

How to Use the Singleton Class in Program.cs

Now let’s see how you can use this Singleton class in your application:

class Program
{
    static void Main(string[] args)
    {
        // Retrieve the single instance of the Singleton class
        Singleton singleton1 = Singleton.Instance;
        singleton1.PrintMessage(); // Output: Hello, I am a singleton class.

        // Retrieve the instance again
        Singleton singleton2 = Singleton.Instance;

        // Check if both instances are the same
        Console.WriteLine(singleton1 == singleton2); // Output: True
    }
}

In this example, we retrieve the Singleton instance twice. Because the class is a Singleton, both singleton1 and singleton2 refer to the same instance. The == operator confirms this by returning true.

How to Extend the Singleton Example

You can expand the Singleton pattern to handle more complex scenarios. For example, you could initialize the Singleton instance with configuration data:

public class ConfigurationManager
{
    private static ConfigurationManager instance;
    private readonly Dictionary<string, string> settings = new Dictionary<string, string>();

    private ConfigurationManager()
    {
        // Simulate loading settings from a configuration file
        settings["AppName"] = "MyApplication";
        settings["Version"] = "1.0.0";
    }

    public static ConfigurationManager Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new ConfigurationManager();
            }
            return instance;
        }
    }

    public string GetSetting(string key)
    {
        return settings.ContainsKey(key) ? settings[key] : null;
    }
}

Here, ConfigurationManager is a Singleton class that loads and manages application settings. The GetSetting method allows you to retrieve specific configuration values, ensuring that all parts of your application use the same settings.

Key Points to Remember About Singleton Classes

• Single instance: Singleton classes ensure that only one instance of the class exists in the application.

• Global access: Singleton provides a global point of access to the instance, making it easy to use across different parts of your application.

• Thread safety: In multi-threaded environments, ensure your Singleton is thread-safe to avoid creating multiple instances.

• Use cases: Common use cases for Singleton include managing configurations, logging services, and database connections.

Singleton classes are a fundamental design pattern in software engineering, offering a simple yet powerful way to manage shared resources. Understanding and correctly implementing Singletons can help you write more efficient and maintainable code.

Generic Classes in C Sharp

Generic classes in C# provide a powerful way to create reusable and type-safe code. By using generic classes, you can design a single class that works with any data type, eliminating the need for type-specific implementations. This makes your code more flexible and reduces redundancy.

Why Use Generic Classes?

Imagine you need to implement a stack that stores integers. Later, you might need another stack to store strings.

Instead of writing two separate classes, you can write one generic stack class that can handle both data types—and any others you might need. Generic classes help you avoid code duplication and make your codebase easier to maintain.

Example: Defining a Generic Class

Let’s take a look at a simple implementation of a generic stack class:

// Define a generic class
public class Stack<T>
{
    private List<T> items = new List<T>();

    public void Push(T item)
    {
        items.Add(item);
    }

    public T Pop()
    {
        if (items.Count == 0)
        {
            throw new InvalidOperationException("The stack is empty.");
        }
        T item = items[items.Count - 1];
        items.RemoveAt(items.Count - 1);
        return item;
    }

    public T Peek()
    {
        if (items.Count == 0)
        {
            throw new InvalidOperationException("The stack is empty.");
        }
        return items[items.Count - 1];
    }

    public bool IsEmpty()
    {
        return items.Count == 0;
    }
}

In this example, the Stack<T> class is defined with a type parameter T. This type parameter is a placeholder that represents the type of data the stack will store. The class includes methods like Push to add an item to the stack, Pop to remove and return the top item, Peek to view the top item without removing it, and IsEmpty to check if the stack is empty.

Because Stack<T> is generic, you can use it with any data type, whether it's int, string, or even a custom class.

How to Use the Stack Class in Program.cs

Let’s see how this generic Stack class can be used in a program:

class Program
{
    static void Main(string[] args)
    {
        // Stack for integers
        Stack<int> intStack = new Stack<int>();
        intStack.Push(10);
        intStack.Push(20);
        Console.WriteLine(intStack.Pop()); // Output: 20
        Console.WriteLine(intStack.Peek()); // Output: 10

        // Stack for strings
        Stack<string> stringStack = new Stack<string>();
        stringStack.Push("Hello");
        stringStack.Push("World");
        Console.WriteLine(stringStack.Pop()); // Output: World
        Console.WriteLine(stringStack.Peek()); // Output: Hello
    }
}

In this example, we create two instances of the Stack class: one that stores integers and another that stores strings. The flexibility of generics allows us to use the same class to work with different data types, making our code more reusable and concise.

How to Extend the Generic Class

Let’s take it a step further and extend our Stack class to include a method that returns all items as an array:

public T[] ToArray()
{
    return items.ToArray();
}

Now, you can easily convert the stack’s items into an array:

int[] intArray = intStack.ToArray();
string[] stringArray = stringStack.ToArray();

This extension further showcases the power of generics, allowing the same method to work with different data types seamlessly.

Key Points to Remember About Generic Classes

• Flexibility: Generic classes can handle any data type, making them adaptable and reusable.

• Type safety: Using type parameters ensures that your code is type-safe, catching errors during compile-time instead of runtime.

• Code reuse: Generics remove the need to duplicate code for different data types, resulting in cleaner and easier-to-maintain code.

• Type parameters: Generic classes use type parameters as placeholders for the actual data types you will use when creating an instance of the class.

Generic classes are crucial in C# for building flexible, reusable, and type-safe code. By learning and using generics, you can create more reliable and maintainable applications.

Internal Classes in C Sharp

Internal classes in C# are a powerful way to encapsulate implementation details within an assembly. By using the internal access modifier, you can restrict access to certain classes, ensuring they are only accessible within the same assembly.

This is particularly useful for hiding complex logic or utility classes that are not intended to be exposed to the public API of your library or application.

Why Use Internal Classes?

In a large application, you may have classes that should only be used internally by your code and not by external consumers. For example, helper classes, utility functions, or components of a larger system that do not need to be exposed outside the assembly can be marked as internal. This ensures that your public API remains clean and focused while still allowing full functionality within the assembly.

Example: Defining an Internal Class

Let’s consider a scenario where you have a library that processes orders. You might have a class that handles the complex logic of calculating discounts, but you don't want this class to be accessible to users of your library. Instead, you only expose the main OrderProcessor class, keeping the discount logic hidden with an internal class.

// Define a public class that uses an internal class
public class OrderProcessor
{
    public void ProcessOrder(int orderId)
    {
        // Internal class is used here
        DiscountCalculator calculator = new DiscountCalculator();
        decimal discount = calculator.CalculateDiscount(orderId);
        Console.WriteLine($"Order {orderId} processed with a discount of {discount:C}");
    }

    // Internal class that handles discount calculations
    internal class DiscountCalculator
    {
        public decimal CalculateDiscount(int orderId)
        {
            // Complex discount calculation logic
            return orderId * 0.05m;
        }
    }
}

In this example, the DiscountCalculator class is marked as internal, meaning it’s only accessible within the assembly. The OrderProcessor class, which is public, uses this internal class to process orders. External users of the library can call ProcessOrder without needing to know about or interact with the DiscountCalculator class.

How to Use the Internal Class in Program.cs

Now, let's see how this works in practice:

class Program
{
    static void Main(string[] args)
    {
        OrderProcessor processor = new OrderProcessor();
        processor.ProcessOrder(12345); // Output: Order 12345 processed with a discount of $617.25
    }
}

In this example, the ProcessOrder method is publicly accessible, but the internal workings of discount calculation remain hidden, providing a clean and secure API.

Key Points to Remember About Internal Classes

• Limited access: Internal classes can only be accessed within the same assembly, which helps keep your public API simple and focused.

• Encapsulation: They are used to hide implementation details, like helper functions or complex logic, that shouldn't be publicly visible.

• Visibility control: The internal access modifier lets you control which classes and members are visible, ensuring only the necessary parts of your code are accessible to other assemblies.

Internal classes are important for managing complex applications, allowing you to control what parts of your code can be accessed from outside your assembly. By hiding details and limiting access, you can keep your codebase clean, easy to maintain, and secure.

Nested Classes in C Sharp

Nested classes in C# are defined within another class. This structure is useful for grouping related classes together and encapsulating the implementation details. Nested classes can be either static or non-static, and they have direct access to the private members of their enclosing class.

Why Use Nested Classes?

Nested classes are particularly useful when a class is closely tied to the logic of another class and isn’t meant to be used independently. They allow you to encapsulate helper classes, hide them from other parts of the program, and keep related code together. This can lead to a cleaner, more organized codebase.

Example: Defining a Nested Class

Let’s consider a scenario where we have a class that represents a Car and another class that represents a Engine. Since the Engine class is closely related to the Car class and doesn’t make much sense on its own, we can define it as a nested class within Car.

// Define a class with a nested class
public class Car
{
    // Define private fields
    private string model;
    private Engine carEngine;

   // Constructor
    public Car(string model)
    {
        this.model = model;
        carEngine = new Engine();
    }


    // Method to start the car
    public void StartCar()
    {
        carEngine.StartEngine();
        Console.WriteLine($"{model} is starting...");
    }

    // Nested class
    public class Engine
    {
        public void StartEngine()
        {
            Console.WriteLine("Engine started.");
        }
    }
}

In this example, the Car class has a private field model and a method StartCar that starts the car. The Engine class is nested within the Car class and contains a StartEngine method. By nesting Engine inside Car, we express the close relationship between the two.

How to Use the Nested Class in Program.cs

Let’s see how we can use the Car class and its nested Engine class in a program:

class Program
{
    static void Main(string[] args)
    {
        Car myCar = new Car("Toyota");
        myCar.StartCar(); // Output: Engine started. Toyota is starting...

        // Although you can create an instance of the nested class separately, it usually makes sense to use it through the outer class
        Car.Engine engine = new Car.Engine();
        engine.StartEngine(); // Output: Engine started.
    }
}

In this example, we create an instance of the Car class and call the StartCar method, which internally calls the StartEngine method of the nested Engine class. While it's possible to instantiate the nested class separately, it’s more common to access it through the outer class, emphasizing the relationship between the two.

Key Points to Remember About Nested Classes

• Encapsulation: Nested classes keep details hidden that shouldn't be seen outside the main class.

• Access to private members: Nested classes can access private parts of the main class, making them good for helper classes that need to work with the main class's internal parts.

• Organization: Use nested classes to keep related classes together, which makes the code cleaner and more organized.

• Static or non-static: Nested classes can be static or non-static. Static nested classes can't access the instance parts of the main class directly, but non-static nested classes can.

Nested classes are a useful way to organize your code, especially for complex objects with closely related parts. Keeping related classes together makes your code easier to manage and maintain.

Partial Classes in C Sharp

Partial classes in C# allow you to split a class definition across multiple files. This feature is particularly useful in large projects, where it can be beneficial to break a complex class into smaller, more manageable sections.

By using the partial keyword, you can organize your code better, especially when working with generated code or collaborating in a team environment.

Why Use Partial Classes?

Imagine you’re working on a large application where a single class contains hundreds of lines of code. This can become difficult to manage and maintain. By using partial classes, you can divide the class into logical parts, each residing in a separate file. This not only makes the code more readable but also allows multiple developers to work on different parts of the class simultaneously without causing merge conflicts.

Example: Defining a Partial Class in C

Let’s say we have a class that handles various operations for an employee management system. Instead of putting all methods in one file, we can split them across multiple files using partial classes.

File 1: PartialClass_Methods1.cs

// Define a partial class
public partial class EmployeeOperations
{
    public void AddEmployee(string name)
    {
        Console.WriteLine($"Employee {name} added.");
    }
}

File 2: PartialClass_Methods2.cs

// Define the other part of the partial class
public partial class EmployeeOperations
{
    public void RemoveEmployee(string name)
    {
        Console.WriteLine($"Employee {name} removed.");
    }
}

In these examples, the EmployeeOperations class is split into two files, each containing a part of the class. The first file handles adding employees, while the second file handles removing them.

How to Use the Partial Class in Program.cs

Now, let’s use the EmployeeOperations class in our Program.cs file:

class Program
{
    static void Main(string[] args)
    {
        EmployeeOperations operations = new EmployeeOperations();

        operations.AddEmployee("John Doe");    // Output: Employee John Doe added.
        operations.RemoveEmployee("John Doe"); // Output: Employee John Doe removed.
    }
}

In this example, the EmployeeOperations class, although defined in multiple files, behaves like a single class. The methods AddEmployee and RemoveEmployee are seamlessly combined, providing a clean and organized way to manage operations.

Key Points to Remember About Partial Classes

• Code organization: Partial classes help keep large classes organized by splitting them into smaller, focused sections.

• Team collaboration: Multiple developers can work on different parts of the same class without interfering with each other’s code.

• Generated code: Often used with auto-generated code, where part of the class is generated by a tool, and the rest is written manually.

Partial classes are a powerful feature in C# that allows for better code management, especially in large-scale applications. By breaking down a class into logical components, you can maintain clean, readable, and maintainable code.

Conclusion

Classes are the building blocks of object-oriented programming in C#. By understanding the different types of classes—abstract, static, sealed, concrete, and singleton—you can create well-structured, maintainable, and efficient code.

Whether you’re designing utility classes, defining abstract interfaces, or encapsulating complex logic, classes play a crucial role in shaping your application’s architecture.

Imagine building robust APIs with minimal code and zero boilerplate—no more wrestling with controllers, routing, or middleware. That’s what minimal APIs allow you to do. The idea with these APIs is to streamline the development process, making it incredibly easy and efficient.

In this article, we'll dive into the world of minimal APIs in .NET 8 and guide you through creating a fully functional bookstore API. You'll learn how to get all books, retrieve a book by its ID, add new books, and even delete books. Let’s get started.

Table of Contents

• Prerequisites

• Introduction to Minimal APIs

• How to Create a Minimal API

• HTTP Methods in Controller-based and Minimal APIs

• Minimal API Project Files

• How to Create the Models

• How to Create the Database Context

• How to Create a Contract

• How to Add Services

• How to Create Exceptions

• How to Create the API Endpoints

• How to Add Seed Data to the Database

• How to Perform a Migration

• How to Test the API Endpoints

• Conclusion

Prerequisites

Before we get going, make sure you have the following prerequisites installed on your machine:

• .NET 8 SDK

• Visual Studio Code or any other code editor of your choice

• C# Dev Kit for Visual Studio Code

Alternatively, you can use Visual Studio 2022, which comes with built-in support for .NET 8. But in this article, we'll be using Visual Studio Code. It’s lightweight, easy to use, and cross-platform.

We’ll use Swagger UI to test our API. Swagger UI is a powerful tool that allows you to interact with your API directly from your browser. It provides a user-friendly interface to test your API endpoints, making it easier to test and debug your API.

When you create a new project, it will automatically install the necessary packages and configure the project to use Swagger UI. .NET 8 includes Swagger UI by default, so whether you create your application in Visual Studio or with .NET, Swagger UI will be configured for you.

Run your application, and the Swagger UI will automatically open in your browser – but since we are using VS Code, we need to click on the port number on our terminal.

You can find the source code for this project on GitHub.

Introduction to Minimal APIs

Imagine working in a codebase with numerous endpoints, making it quite large and complex. Traditionally, building an API in ASP.NET Core involves using controllers, routing, middleware, and a significant amount of boilerplate code. But there are two approaches to building an API in ASP.NET Core: the traditional way and the minimal way.

The traditional way is familiar to most developers, involving controllers and extensive infrastructure code. The minimal way, introduced in .NET 6, allows you to create APIs with minimal code and zero boilerplate. This approach simplifies the development process, enabling you to focus on writing business logic rather than dealing with infrastructure code.

Minimal APIs are lightweight, fast, and perfect for building small to medium-sized APIs. They are ideal for prototyping, building microservices, or creating simple APIs that don't require much complexity. In this handbook, we'll explore the world of minimal APIs in .NET 6 and learn how to create a fully functional bookstore API from scratch.

How to Create a Minimal API

Creating a minimal API is straightforward when using the dotnet CLI, as the default template is already a minimal API. But if you use Visual Studio, you'll need to remove the boilerplate code that comes with the project template.

Let's start by using the dotnet CLI to create a minimal API project.

dotnet new webapi  -n BookStoreApi

The dotnet new webapi command creates a new minimal API project named BookStoreApi. This project contains the necessary files and folders to get you started.

Let's explore the project structure:

• Program.cs: The entry point of the application, where the host is configured.

• bookapi-minimal.sln: The solution file that contains the project.

• bookapi-minimal.http: A file that contains sample HTTP requests to test the API.

• bookapi-minimal.csproj: The project file that contains the project configuration.

• appsettings.json: The configuration file that stores application settings.

• appsettings.Development.json : The configuration file for the development environment.

When you open the program.cs file, you'll notice that the code is minimal. The Program.cs file contains the following code:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast")
.WithOpenApi();

app.Run();

record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

If you don't fully understand the code yet, don't worry—we'll cover it in detail in the upcoming sections. The key takeaway is that minimal APIs require very little code, which is one of their main advantages.

The default code sets up a simple weather forecast API that you can use to test your setup. It generates a list of weather forecasts and returns them when you make a GET request to the /weatherforecast endpoint. Also, the code includes Swagger UI to help you test the API.

Pay special attention to the app.MapGet method, which maps a route to a handler function. In this case, it maps the /weatherforecast route to a function that returns a list of weather forecasts. We'll use similar methods to create our own endpoints in the next sections.

Before we start creating our project folder structure, let's understand the HTTP methods in both Controller-based and Minimal APIs.

HTTP Methods in Controller-based and Minimal APIs

In a Controller-based approach, which is the traditional way of creating web APIs, you need to create a controller class and define methods for each HTTP method. For example:

• To create a GET method, you use the [HttpGet] attribute.

• To create a POST method, you use the [HttpPost] attribute.

• To create a PUT method, you use the [HttpPut] attribute.

• To create a DELETE method, you use the [HttpDelete] attribute.

This is how endpoints are created in a Controller-based approach.

In contrast, Minimal APIs use methods like app.MapGet, app.MapPost, app.MapPut, and app.MapDelete to create endpoints. This is the main difference between the two approaches: Controller-based APIs use attributes to define endpoints, while Minimal APIs use methods.

Now that you understand how to handle HTTP requests in both Controller-based and Minimal APIs, let's create our project folder structure.

Before we create our project folder structure, let's first run what we have. As we learned earlier, when you create a project with either Visual Studio or .NET CLI, it comes with a default WeatherForecast project which we can run and see on the UI. Let's run it to ensure everything works before we go on to create our project folder.

Run this command:

dotnet run

You should see the following output:

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5228
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: D:\Devolopemnt\Dotnet\bookapi-minimal

This means the application is running and listening on http://localhost:5228. As I mentioned above, since we are using the dotnet CLI and Visual Studio Code, the application will not automatically open the browser for us. We need to do this manually.

Open your browser and navigate to http://localhost:5228/swagger/index.html to see the default response from the API.

You should see something like this:

Now the next thing for us to do is find a way to structure our project and create the necessary files and folders to get us started.

Minimal API Project Files

To organize our project, we will create a structured folder hierarchy. This will help keep our code clean and maintainable. Here is the folder structure we will use:

• AppContext: Contains the database context and related configurations.

• Configurations: Holds Entity Framework Core configurations and seed data for the database.

• Contracts: Contains Data Transfer Objects (DTOs) used in our application.

• Endpoints: Where we define and configure our minimal API endpoints.

• Exceptions: Contains custom exception classes used in the project.

• Extensions: Holds extension methods that we will use throughout the project.

• Models: Contains business logic models.

• Services: Contains service classes that implement business logic.

• Interfaces: Holds interface definitions used to map our services.

In Visual Studio Code, you can create this folder structure as follows:

- AppContext
- Configurations
- Contracts
- Endpoints
- Exceptions
- Extensions
- Models
- Services
- Interfaces

After setting up, your project folder structure should look like this:

Now that our project Structure is set up we can go ahead and start writing our code. Let's start by creating our models.

How to Create the Models

In this section, we will create models for our application. Models are the building blocks of our application, representing the data that our application will work with. For our example, we will create a model for a book.

To get started, create a folder named Models in your project directory. Inside this folder, create a file named BookModel.cs and add the following code:

// Models/BookModel.cs


namespace bookapi_minimal.Models
{
    public class BookModel
    {
        public Guid Id { get; set; }
        public string Title { get; set; }
        public string Author { get; set; }
        public string Description { get; set; }
        public string Category { get; set; }
        public string Language { get; set; }
        public int TotalPages { get; set; }
    }
}

This BookModel class defines the properties that represent the details of a book, such as its title, author, description, category, language, and total pages. Each property is designed to hold specific information about the book, making it easy to manage and manipulate book data within our application.

Now that we have created our model, let's create our database context.

How to Create the Database Context

The database context is a class that represents a session with the database. It’s responsible for interacting with the database and executing database operations. In our application, we will use Entity Framework Core to interact with our database.

Install the Required Packages

Before creating our database context, we need to install the following packages:

• Microsoft.EntityFrameworkCore.Design

• Microsoft.EntityFrameworkCore

• Microsoft.EntityFrameworkCore.SqlServer

• Microsoft.EntityFrameworkCore.Tools

• FluentValidation.DependencyInjectionExtensions

You can install these packages using the following commands:

dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools
dotnet add package FluentValidation.DependencyInjectionExtensions

Verify Package Installation

To verify that the packages are installed, open the bookapi-minimal.csproj file in your project's root directory. You should see the installed packages listed as follows:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <RootNamespace>bookapi_minimal</RootNamespace>
  </PropertyGroup>

  <ItemGroup>
   <PackageReference Include="FluentValidation.DependencyInjectionExtensions" Version="11.9.2" />
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="8.0.6" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.8" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="8.0.8">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="8.0.8" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="8.0.8">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
  </ItemGroup>

</Project>

This confirms that the packages have been successfully installed.

Now let's create our database context.

In the AppContext folder, create a new file named ApplicationContext.cs and add the following code:

// AppContext/ApplicationContext.cs

using bookapi_minimal.Models;
using Microsoft.EntityFrameworkCore;

namespace bookapi_minimal.AppContext
{

    public class ApplicationContext(DbContextOptions<ApplicationContext> options) : DbContext(options)
    {

        // Default schema for the database context
        private const string DefaultSchema = "bookapi";


       // DbSet to represent the collection of books in our database
        public DbSet<BookModel> Books { get; set; }

        // Constructor to configure the database context

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

            modelBuilder.ApplyConfigurationsFromAssembly(typeof(ApplicationContext).Assembly);

            modelBuilder.ApplyConfigurationsFromAssembly(typeof(ApplicationContext).Assembly);

        }

    }
}

Let's break down the code above:

• We define a class named ApplicationContext that inherits from DbContext. The DbContext class is part of Entity Framework Core and represents a session with the database.

• The constructor accepts an instance of DbContextOptions<ApplicationContext>. This constructor is used to configure the database context options.

• We define a property named Books type DbSet<BookModel>. This property represents the collection of books in our database.

• We override the OnModelCreating method to configure the database schema and apply any configurations defined in our application.

Now that we have created our database context, let's create our extension method and register our database context in the dependency injection container.

Create an Extension Method

Before we create the extension method, let's understand what an extension method is in the context of ASP.NET Core.

An extension method is a static method that adds new functionality to an existing type without modifying the original type. In ASP.NET Core, extension methods are commonly used to extend the functionality of the IServiceCollection interface, which is used to register services in the dependency injection container.

Services are components that provide functionality to an application, such as database access, logging, and configuration. By creating an extension method for the IServiceCollection interface, you can simplify the process of registering your services in the dependency injection container.

Instead of putting everything in the Program.cs file, we will create an extension method to register our services in the dependency injection container. This will help us keep our code clean and organized.

In the Extensions folder, create a new file named ServiceExtensions.cs and add the following code:

using System.Reflection;
using bookapi_minimal.AppContext;
using FluentValidation;
using Microsoft.EntityFrameworkCore;

namespace bookapi_minimal.Extensions
{
    public static class ServiceExtensions
    {
        public static void AddApplicationServices(this IHostApplicationBuilder builder)
        {
            if (builder == null) throw new ArgumentNullException(nameof(builder));
            if (builder.Configuration == null) throw new ArgumentNullException(nameof(builder.Configuration));

            // Adding the database context
            builder.Services.AddDbContext<ApplicationContext>(configure =>
            {
                configure.UseSqlServer(builder.Configuration.GetConnectionString("sqlConnection"));
            });

            // Adding validators from the current assembly
            builder.Services.AddValidatorsFromAssembly(Assembly.GetExecutingAssembly());
        }
    }
}

Let's break down the code above:

• We define a static class named ServiceExtensions that contains an extension method named AddApplicationServices. This method extends the IHostApplicationBuilder interface, which is used to configure the application's request processing pipeline.

• The AddApplicationServices method accepts an instance of IHostApplicationBuilder as a parameter. This parameter is used to access the application's configuration and services.

• We add the ApplicationContext to the dependency injection container and configure it to use SQL Server as the database provider. We retrieve the connection string from the appsettings.json file using the GetConnectionString method.

• We add validators from the current assembly using the AddValidatorsFromAssembly method. This method scans the current assembly for classes that implement the IValidator interface and registers them in the dependency injection container.

Next, we need to add the connection string to the appsettings.json file. Add the following code to your appsettings.json file:

{ 
     "ConnectionStrings": {
    "sqlConnection": "Server=localhost\\SQLEXPRESS02;Database=BookAPIMinimalAPI;Integrated Security=true;TrustServerCertificate=true;"
  }
  }

Make sure to replace your_password it with your actual SQL Server password.

Your appsettings.json file should look like this:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "ConnectionStrings": {
    "sqlConnection": "Server=localhost\\SQLEXPRESS02;Database=BookAPIMinimalAPI;Integrated Security=true;TrustServerCertificate=true;"
  },
  "AllowedHosts": "*"
}

Congratulations! You have successfully created the database context, extension method, and connection string for your application. In the next section, we will create a Contract.

How to Create a Contract

Contracts are Data Transfer Objects (DTOs) that define the structure of the data exchanged between the client and the server. In our application, we will create contracts to represent the data sent and received by our API endpoints.

Here are the contracts we are going to create:

• CreateBookRequest: This represents the data sent when creating a new book.

• UpdateBookRequest: tHI Represents the data sent when updating an existing book.

• BookResponse: Represents the data returned when retrieving a book.

• ErrorResponse: Represents the error response returned when an exception occurs.

• ApiResponse: Represents the response returned by the API.

In the Contracts folder, create a new file named CreateBookRequest and add the following code:

// Contracts/CreateBookRequest.cs

namespace bookapi_minimal.Contracts
{

    public record CreateBookRequest
    { 

        public string Title { get; init; }
        public string Author { get; init; }
        public string Description { get; init; }
        public string Category { get; init; }
        public string Language { get; init; }
        public int TotalPages { get; init; }
    }
}

In the Contracts folder, create a new file named UpdateBookRequest and add the following code:

// Contracts/UpdateBookRequest.cs

namespace bookapi_minimal.Contracts
{

    public record UpdateBookRequest
    {
       public string Title { get; set; }
        public string Author { get; set; }
        public string Description { get; set; }
        public string Category { get; set; }
        public string Language { get; set; }
        public int TotalPages { get; set; }

    }
}

In the Contracts folder, create a new file named BookResponse and add the following code:

// Contracts/BookResponse.cs
namespace bookapi_minimal.Contracts
{

    public record BookResponse
    {
        public Guid Id { get; set; }
        public string Title { get; set; }
        public string Author { get; set; }
        public string Description { get; set; }
        public string Category { get; set; }
        public string Language { get; set; }
        public int TotalPages { get; set; }
    }
}

In the Contracts folder, create a new file named ErrorResponse and add the following code:

// Contracts/ErrorResponse.cs
namespace bookapi_minimal.Contracts
{

        public record ErrorResponse
    {
        public string Title { get; set; }
        public int StatusCode { get; set; }
        public string Message { get; set; }

    }

}

In the Contracts folder, create a new file named ApiResponse and add the following code:

// Contracts/ApiResponse.cs
namespace bookapi_minimal.Contracts
{

    public class ApiResponse<T>
    {
        public T Data { get; set; }
        public string Message { get; set; }

        public ApiResponse(T data, string message)
        {
            Data = data;
            Message = message;
        }
    }
}

These contracts help us define the structure of the data exchanged between the client and the server, making it easier to work with the data in our application.

In the next section, we will create services to implement the business logic of our application.

How to Add Services

Services are components that provide functionality to an application. In our application, we will create services to implement the business logic of our application. We will create services to handle CRUD operations for books, validate book data, and handle exceptions.

In ASP.NET Core, services are registered in the dependency injection container and can be injected into other components, such as controllers and endpoints, But this is a minimal API so we will inject the services directly into the endpoints.

Let's create an interface for our services. In the Interfaces folder, create a new file named IBookService.cs and add the following code:

 // Interfaces/IBookService.cs



using bookapi_minimal.Contracts;

namespace bookapi_minimal.Interfaces
{
      public interface IBookService
    {
        Task<BookResponse> AddBookAsync(CreateBookRequest createBookRequest);
        Task<BookResponse> GetBookByIdAsync(Guid id);
        Task<IEnumerable<BookResponse>> GetBooksAsync();
        Task<BookResponse> UpdateBookAsync(Guid id,  UpdateBookRequest  updateBookRequest);
        Task<bool> DeleteBookAsync(Guid id);
    }
}

Let's break down the code above: We have defined an interface named IBookService that contains methods to handle CRUD operations for books. The interface defines the following methods:

• AddBookAsync: Adds a new book to the database.

• GetBookByIdAsync: Retrieves a book by its ID.

• GetBooksAsync: Retrieves all books from the database.

• UpdateBookAsync: Updates an existing book.

We are using the Contract we created earlier in the Contracts folder. The IBookService interface defines the structure of the methods that will be implemented by the service classes. This helps us separate the interface from the implementation, making it easier to maintain and test our code.

Now that we have created the interface, let's create the service class that implements the interface.

How to Implement the Book Service

This service will implement the IBookService interface and provide the business logic for our application. In the Services folder, create a new file named BookService.cs . Your initial file should look like this:

// Services/BookService.cs

namespace bookapi_minimal.Services
{
    public class BookService
    {

    }
}

The first thing we need to do is add the interface to the BookService class. Update the BookService class to implement the IBookService interface as follows:

// Services/BookService.cs



using bookapi_minimal.Interfaces;

namespace bookapi_minimal.Services
{
    public class BookService:IBookService
    {

    }
}

When you do this, your VS Code might show an error because we have not implemented the methods in the interface. Let's go ahead and implement the methods in the BookService class.

In VS Code you can use the Ctrl + . shortcut to implement the methods in the interface. Then you will see the following code generated for you:

using bookapi_minimal.Contracts;
using bookapi_minimal.Interfaces;

namespace bookapi_minimal.Services
{
     // Service class for managing books
   public class BookService : IBookService
   {
       // Method to add a new book to the database
       public Task<BookResponse> AddBookAsync(CreateBookRequest createBookRequest)
       {
           throw new NotImplementedException();
       }

      // Method to Delete a book from the database
       public Task<bool> DeleteBookAsync(Guid id)
       {
           throw new NotImplementedException();
       }

       // Method to Get a book from the database by its ID

       public Task<BookResponse> GetBookByIdAsync(Guid id)
       {
           throw new NotImplementedException();
       }

      // Method to Get all books from the database
       public Task<IEnumerable<BookResponse>> GetBooksAsync()
       {
           throw new NotImplementedException();
       }

       // Method to Update a book in the database
       public Task<BookResponse> UpdateBookAsync(Guid id, UpdateBookRequest updateBookRequest)
       {
           throw new NotImplementedException();
       }
   }
}

Now you can see that the methods in the interface have been implemented in the BookService class. We will implement the business logic for each method in the next section.

Before we do that, let's add the necessary dependencies to the BookService class. We need to inject the ApplicationContext and ILogger dependencies into the BookService class. ApplicationContext is used to interact with the database, while ILogger is used for logging.

To inject the dependencies, update the BookService class as follows:

// Services/BookService.cs

// ...
 private readonly ApplicationContext _context; // Database context
  private readonly ILogger<BookService> _logger; // Logger for logging information and errors

//..

Since we have added the dependencies, we need to update the BookService constructor to accept the dependencies. Update the BookService constructor as follows:

// Services/BookService.cs

// ...

  // Constructor to initialize the database context and logger
 public BookService(ApplicationContext context, ILogger<BookService> logger)
 {
            _context = context;
            _logger = logger;
}

// ...

Now that we have added the dependencies and updated the constructor, we can implement the business logic for each method in the BookService class.

Let's create logic for the CREATE, READ, UPDATE, and DELETE operations in the BookService class.

How to Implement the AddBookAsync Method

As I mentioned earlier, we’ll use the AddBookAsync method to add a new book to the database. In this method, we will create a new book entity, map the data from the CreateBookRequest object to the book entity, and save the book entity to the database. We will also return the book entity as an BookResponse object.

Update the AddBookAsync method in the BookService class as follows:

// Services/BookService.cs

// ...
 /// <summary>
        /// Add a new book
        /// </summary>
        /// <param name="createBookRequest">Book request to be added</param>
        /// <returns>Details of the created book</returns>
        public async Task<BookResponse> AddBookAsync(CreateBookRequest createBookRequest)
        {
            try
            {
                var book = new BookModel
                {
                    Title = createBookRequest.Title,
                    Author = createBookRequest.Author,
                    Description = createBookRequest.Description,
                    Category = createBookRequest.Category,
                    Language = createBookRequest.Language,
                    TotalPages = createBookRequest.TotalPages
                };

                // Add the book to the database
                _context.Books.Add(book);
                await _context.SaveChangesAsync();
                _logger.LogInformation("Book added successfully.");

                // Return the details of the created book
                return new BookResponse
                {
                    Id = book.Id,
                    Title = book.Title,
                    Author = book.Author,
                    Description = book.Description,
                    Category = book.Category,
                    Language = book.Language,
                    TotalPages = book.TotalPages
                };
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error adding book: {ex.Message}");
                throw;
            }
        }
// ...

In this code, we are creating a new book entity from the CreateBookRequest object, mapping the data from the CreateBookRequest object to the book entity, saving the book entity to the database, and returning the book entity as a BookResponse object.

We are also logging information and errors using the ILogger dependency. If an exception occurs during the process, we log the error message and rethrow the exception.

Now that we have implemented the AddBookAsync method, let's implement the GetBookByIdAsync method.

How to Implement the GetBookByIdAsync Method

The GetBookByIdAsync method is used to retrieve a book by its ID from the database. In this method, we will query the database for the book with the specified ID, map the book entity to a BookResponse object, and return the BookResponse object.

Update the GetBookByIdAsync method in the BookService class as follows:

// Services/BookService.cs

//... 

    /// <summary>
        /// Get a book by its ID
        /// </summary>
        /// <param name="id">ID of the book</param>
        /// <returns>Details of the book</returns>
        public async Task<BookResponse>  GetBookByIdAsync(Guid id)
        {
            try
            {
                // Find the book by its ID
                var book = await _context.Books.FindAsync(id);
                if (book == null)
                {
                    _logger.LogWarning($"Book with ID {id} not found.");
                    return null;
                }

                // Return the details of the book
                return new BookResponse
                {
                    Id = book.Id,
                    Title = book.Title,
                    Author = book.Author,
                    Description = book.Description,
                    Category = book.Category,
                    Language = book.Language,
                    TotalPages = book.TotalPages
                };
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error retrieving book: {ex.Message}");
                throw;
            }
        }

//...

In this code, we are querying the database for the book with the specified ID, mapping the book entity to a BookResponse object, and returning the BookResponse object. We are also logging information and errors using the ILogger dependency.

If the book with the specified ID is not found, we log a warning message and return null. If an exception occurs during the process, we log the error message and rethrow the exception.

Now that we have implemented the GetBookByIdAsync method, let's implement the GetBooksAsync method.

How to Implement the GetBooksAsync Method

The GetBooksAsync method is used to retrieve all books from the database. In this method, we will query the database for all books, map each book entity to a BookResponse object, and return a list of BookResponse objects.

Update the GetBooksAsync method in the BookService class as follows:

// Services/BookService.cs

//... 


  /// <summary>
        /// Get all books
        /// </summary>
        /// <returns>List of all books</returns>
        public async Task<IEnumerable<BookResponse>> GetBooksAsync()
        {
            try
            {
                // Get all books from the database
                var books = await _context.Books.ToListAsync();

                // Return the details of all books
                return books.Select(book => new BookResponse
                {
                    Id = book.Id,
                    Title = book.Title,
                    Author = book.Author,
                    Description = book.Description,
                    Category = book.Category,
                    Language = book.Language,
                    TotalPages = book.TotalPages
                });
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error retrieving books: {ex.Message}");
                throw;
            }
        }
//...

Here, we are querying the database for all books, mapping each book entity to an BookResponse object, and returning a list of BookResponse objects. We are also logging information and errors using the ILogger dependency. If an exception occurs during the process, we log the error message and rethrow the exception.

Now that we have implemented the GetBooksAsync method, let's implement the UpdateBookAsync method.

How to Implement the UpdateBookAsync Method

The UpdateBookAsync method is used to update an existing book in the database. In this method, we will query the database for the book with the specified ID, update the book entity with the data from the UpdateBookRequest object, save the updated book entity to the database, and return the updated book entity as a BookResponse object.

Update the UpdateBookAsync method in the BookService class as follows:

// Services/BookService.cs
 //...
 /// <summary>
        /// Update an existing book
        /// </summary>
        /// <param name="id">ID of the book to be updated</param>
        /// <param name="book">Updated book model</param>
        /// <returns>Details of the updated book</returns>
        public async Task<BookResponse> UpdateBookAsync(Guid id, UpdateBookRequest book)
        {
            try
            {
                // Find the existing book by its ID
                var existingBook = await _context.Books.FindAsync(id);
                if (existingBook == null)
                {
                    _logger.LogWarning($"Book with ID {id} not found.");
                    return null;
                }

                // Update the book details
                existingBook.Title = book.Title;
                existingBook.Author = book.Author;
                existingBook.Description = book.Description;
                existingBook.Category = book.Category;
                existingBook.Language = book.Language;
                existingBook.TotalPages = book.TotalPages;

                // Save the changes to the database
                await _context.SaveChangesAsync();
                _logger.LogInformation("Book updated successfully.");

                // Return the details of the updated book
                return new BookResponse
                {
                    Id = existingBook.Id,
                    Title = existingBook.Title,
                    Author = existingBook.Author,
                    Description = existingBook.Description,
                    Category = existingBook.Category,
                    Language = existingBook.Language,
                    TotalPages = existingBook.TotalPages
                };
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error updating book: {ex.Message}");
                throw;
            }
        }
//...

Here, we are querying the database for the book with the specified ID, updating the book entity with the data from the UpdateBookRequest object, saving the updated book entity to the database, and returning the updated book entity as a BookResponse object. We are also logging information and errors using the ILogger dependency.

If the book with the specified ID is not found, we log a warning message and return null. If an exception occurs during the process, we log the error message and rethrow the exception.

Now that we have implemented the UpdateBookAsync method, let's implement the DeleteBookAsync method.

How to Implement the DeleteBookAsync Method

The DeleteBookAsync method is used to delete an existing book from the database. In this method, we will query the database for the book with the specified ID, remove the book entity from the database, and return a boolean value indicating whether the book was successfully deleted.

Update the DeleteBookAsync method in the BookService class as follows:

// Services/BookService.cs

 //...


/// <summary>
        /// Delete a book by its ID
        /// </summary>
        /// <param name="id">ID of the book to be deleted</param>
        /// <returns>True if the book was deleted, false otherwise</returns>
        public async Task<bool> DeleteBookAsync(Guid id)
        {
            try
            {
                // Find the book by its ID
                var book = await _context.Books.FindAsync(id);
                if (book == null)
                {
                    _logger.LogWarning($"Book with ID {id} not found.");
                    return false;
                }

                // Remove the book from the database
                _context.Books.Remove(book);
                await _context.SaveChangesAsync();
                _logger.LogInformation($"Book with ID {id} deleted successfully.");
                return true;
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error deleting book: {ex.Message}");
                throw;
            }
        }
//...

In this code, we are querying the database for the book with the specified ID, removing the book entity from the database, and returning a boolean value indicating whether the book was successfully deleted. We are also logging information and errors using the ILogger dependency.

If the book with the specified ID is not found, we log a warning message and return false. If an exception occurs during the process, we log the error message and rethrow the exception.

Now you have successfully implemented the business logic for the AddBookAsync, GetBookByIdAsync, GetBooksAsync, UpdateBookAsync, and DeleteBookAsync methods in the BookService class. These methods handle the CRUD operations for books, validate book data, and handle exceptions. By now, your BookService class should look like this:

using bookapi_minimal.AppContext;
using bookapi_minimal.Contracts;
using bookapi_minimal.Interfaces;
using bookapi_minimal.Models;
using Microsoft.EntityFrameworkCore;

namespace bookapi_minimal.Services
{
    public class BookService : IBookService
    {
          private readonly ApplicationContext _context; // Database context
        private readonly ILogger<BookService> _logger; // Logger for logging information and error
          // Constructor to initialize the database context and logger
        public BookService(ApplicationContext context, ILogger<BookService> logger)
        {
            _context = context;
            _logger = logger;
        }

           /// Add a new book
        /// </summary>
        /// <param name="createBookRequest">Book request to be added</param>
        /// <returns>Details of the created book</returns>
        public async Task<BookResponse> AddBookAsync(CreateBookRequest createBookRequest)
        {
            try
            {
                var book = new BookModel
                {
                    Title = createBookRequest.Title,
                    Author = createBookRequest.Author,
                    Description = createBookRequest.Description,
                    Category = createBookRequest.Category,
                    Language = createBookRequest.Language,
                    TotalPages = createBookRequest.TotalPages
                };

                // Add the book to the database
                _context.Books.Add(book);
                await _context.SaveChangesAsync();
                _logger.LogInformation("Book added successfully.");

                // Return the details of the created book
                return new BookResponse
                {
                    Id = book.Id,
                    Title = book.Title,
                    Author = book.Author,
                    Description = book.Description,
                    Category = book.Category,
                    Language = book.Language,
                    TotalPages = book.TotalPages
                };
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error adding book: {ex.Message}");
                throw;
            }
        }

          /// <summary>
        /// Get a book by its ID
        /// </summary>
        /// <param name="id">ID of the book</param>
        /// <returns>Details of the book</returns>
        public async Task<BookResponse>  GetBookByIdAsync(Guid id)
        {
            try
            {
                // Find the book by its ID
                var book = await _context.Books.FindAsync(id);
                if (book == null)
                {
                    _logger.LogWarning($"Book with ID {id} not found.");
                    return null;
                }

                // Return the details of the book
                return new BookResponse
                {
                    Id = book.Id,
                    Title = book.Title,
                    Author = book.Author,
                    Description = book.Description,
                    Category = book.Category,
                    Language = book.Language,
                    TotalPages = book.TotalPages
                };
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error retrieving book: {ex.Message}");
                throw;
            }
        }



  /// <summary>
        /// Get all books
        /// </summary>
        /// <returns>List of all books</returns>
        public async Task<IEnumerable<BookResponse>> GetBooksAsync()
        {
            try
            {
                // Get all books from the database
                var books = await _context.Books.ToListAsync();

                // Return the details of all books
                return books.Select(book => new BookResponse
                {
                    Id = book.Id,
                    Title = book.Title,
                    Author = book.Author,
                    Description = book.Description,
                    Category = book.Category,
                    Language = book.Language,
                    TotalPages = book.TotalPages
                });
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error retrieving books: {ex.Message}");
                throw;
            }
        }


         /// <summary>
        /// Update an existing book
        /// </summary>
        /// <param name="id">ID of the book to be updated</param>
        /// <param name="book">Updated book model</param>
        /// <returns>Details of the updated book</returns>
        public async Task<BookResponse> UpdateBookAsync(Guid id, UpdateBookRequest book)
        {
            try
            {
                // Find the existing book by its ID
                var existingBook = await _context.Books.FindAsync(id);
                if (existingBook == null)
                {
                    _logger.LogWarning($"Book with ID {id} not found.");
                    return null;
                }

                // Update the book details
                existingBook.Title = book.Title;
                existingBook.Author = book.Author;
                existingBook.Description = book.Description;
                existingBook.Category = book.Category;
                existingBook.Language = book.Language;
                existingBook.TotalPages = book.TotalPages;

                // Save the changes to the database
                await _context.SaveChangesAsync();
                _logger.LogInformation("Book updated successfully.");

                // Return the details of the updated book
                return new BookResponse
                {
                    Id = existingBook.Id,
                    Title = existingBook.Title,
                    Author = existingBook.Author,
                    Description = existingBook.Description,
                    Category = existingBook.Category,
                    Language = existingBook.Language,
                    TotalPages = existingBook.TotalPages
                };
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error updating book: {ex.Message}");
                throw;
            }
        }



        /// <summary>
        /// Delete a book by its ID
        /// </summary>
        /// <param name="id">ID of the book to be deleted</param>
        /// <returns>True if the book was deleted, false otherwise</returns>
        public async Task<bool> DeleteBookAsync(Guid id)
        {
            try
            {
                // Find the book by its ID
                var book = await _context.Books.FindAsync(id);
                if (book == null)
                {
                    _logger.LogWarning($"Book with ID {id} not found.");
                    return false;
                }

                // Remove the book from the database
                _context.Books.Remove(book);
                await _context.SaveChangesAsync();
                _logger.LogInformation($"Book with ID {id} deleted successfully.");
                return true;
            }
            catch (Exception ex)
            {
                _logger.LogError($"Error deleting book: {ex.Message}");
                throw;
            }
        }

    }
}

Congratulations! You have successfully implemented the business logic for the AddBookAsync, GetBookByIdAsync, GetBooksAsync, UpdateBookAsync, and DeleteBookAsync methods in the BookService class.

There's one thing we need to do: we need to register the service in our extension method. Let's go ahead and do that.

In your ServiceExtensions.cs file, add the following code:

// Extensions/ServiceExtensions.cs

//..

 builder.Services.AddScoped<IBookService, BookService>();
//...

This will register the BookService class as a scoped service. This means that the service will be created once per request and disposed of after the request is complete.

Now that we have the service working, let's go ahead and create the exception classes.

How to Create Exceptions

Properly handling exceptions is crucial for ensuring the stability and reliability of an application. In the context of ASP.NET Core, there are two main types of exceptions:

• System Exceptions: These are exceptions thrown by the .NET runtime or the underlying system.

• Application Exceptions: These are exceptions thrown by the application code to handle specific errors or conditions.

In ASP.NET Core with .NET 8, a new feature called global exception handling was introduced. This feature allows you to handle exceptions globally in your application, making it easier to manage errors and provide a consistent user experience.

In our application, we will create custom exception classes to handle specific errors and conditions. We’ll also leverage the global exception handling feature to manage exceptions globally, ensuring a uniform approach to error handling across the entire application.

We are going to create the following exception classes:

• NoBookFoundException: Thrown when a book with the specified ID is not found.

• BookDoesNotExistException: Thrown when a book with the specified ID does not exist.

• GlobalExceptionHandler: Handles exceptions globally in the application.

In the Exceptions folder, create a new file named NoBookFoundException.cs and add the following code:

// Exceptions/NoBookFoundException.cs

namespace bookapi_minimal.Exceptions
{

    public class NoBookFoundException : Exception
    {

        public NoBookFoundException() : base("No books found")
        {}
    }
}

In this code, we are creating a custom exception class named NoBookFoundException that inherits from the Exception class. The NoBookFoundException class is used to handle the scenario where no books are found in the database. We are also providing a custom error message for the exception.

In the Exceptions folder, create a new file named BookDoesNotExistException.cs and add the following code:

namespace bookapi_minimal.Exceptions
{
     public class BookDoesNotExistException : Exception
    {
        private int id { get; set; }

        public BookDoesNotExistException(int id) : base($"Book with id {id} does not exist")
        {
            this.id = id;
        } 

    }
}

In this code, we are creating a custom exception class named BookDoesNotExistException that inherits from the Exception class. The BookDoesNotExistException class is used to handle the scenario where a book with the specified ID does not exist in the database. We are also providing a custom error message for the exception.

In the Exceptions folder, create a new file named GlobalExceptionHandler.cs and add the following code:

// Exceptions/GlobalExceptionHandler.cs

using System.Net;
using bookapi_minimal.Contracts;
using Microsoft.AspNetCore.Diagnostics;

namespace bookapi_minimal.Exceptions
{

   // Global exception handler class implementing IExceptionHandler
    public class GlobalExceptionHandler : IExceptionHandler
    {
        private readonly ILogger<GlobalExceptionHandler> _logger;

        // Constructor to initialize the logger
        public GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger)
        {
            _logger = logger;
        }

        // Method to handle exceptions asynchronously
        public async ValueTask<bool> TryHandleAsync(
            HttpContext httpContext,
            Exception exception,
            CancellationToken cancellationToken)
        {
            // Log the exception details
            _logger.LogError(exception, "An error occurred while processing your request");

            var errorResponse = new ErrorResponse
            {
                Message = exception.Message,
                Title = exception.GetType().Name
            };

            // Determine the status code based on the type of exception
            switch (exception)
            {
                case BadHttpRequestException:
                    errorResponse.StatusCode = (int)HttpStatusCode.BadRequest;
                    break;

                case NoBookFoundException:
                case BookDoesNotExistException:
                    errorResponse.StatusCode = (int)HttpStatusCode.NotFound;
                    break;

                default:
                    errorResponse.StatusCode = (int)HttpStatusCode.InternalServerError;
                    break;
            }

            // Set the response status code
            httpContext.Response.StatusCode = errorResponse.StatusCode;

            // Write the error response as JSON
            await httpContext.Response.WriteAsJsonAsync(errorResponse, cancellationToken);

            // Return true to indicate that the exception was handled
            return true;
        }
    }
}

Let's break down the code above:

• We define a class named GlobalExceptionHandler that implements the IExceptionHandler interface. The IExceptionHandler interface is used to handle exceptions globally in the application.

• The GlobalExceptionHandler class contains a constructor that initializes the ILogger<GlobalExceptionHandler> dependency. The ILogger is used for logging information and errors.

• The TryHandleAsync method is used to handle exceptions asynchronously. This method accepts the HttpContext, Exception, and CancellationToken as parameters.

• We log the exception details using the ILogger dependency.

• We create an ErrorResponse object to represent the error response returned by the API. The ErrorResponse object contains the error message, title, and status code.

• We determine the status code based on the type of exception. If the exception is a BadHttpRequestException, we set the status code to BadRequest. If the exception is a NoBookFoundException or BookDoesNotExistException, we set the status code to NotFound. Otherwise, we set the status code to InternalServerError.

• We set the response status code using the httpContext.Response.StatusCode property.

• We write the error response as JSON using the httpContext.Response.WriteAsJsonAsync method.

• We return true to indicate that the exception was handled successfully.

Now that we have created the exception classes, let's register the GlobalExceptionHandler in the dependency injection container. Since we created an Extension method for registering services in the dependency injection container, we will add the GlobalExceptionHandler to the ServiceExtensions class.

Update the ServiceExtensions class in the Extensions folder as follows:

// Extensions/ServiceExtensions.cs
//...
builder.Services.AddExceptionHandler<GlobalExceptionHandler>();

builder.Services.AddProblemDetails();

//...

The AddExceptionHandler method registers the GlobalExceptionHandler in the dependency injection container. The AddProblemDetails method registers the ProblemDetails class in the dependency injection container.

Now that we have registered the GlobalExceptionHandler in the dependency injection container, we can use it to handle exceptions globally in our application. In the next section, we will create the API endpoints to interact with the book data.

How to Create the API Endpoints

In the context of minimal APIs in ASP.NET Core, there are many ways to set up your endpoints.

You can define them directly in your Program.cs file. But as your project grows and you need to add more endpoints or functionality, it’s helpful to organize your code better. One way to achieve this is by creating a separate class to handle all the endpoints.

As we’ve discussed above, minimal APIs don’t use controllers or views like traditional ASP.NET Core applications. Instead, they use methods such as MapGet, MapPost, MapPut, and MapDelete to define HTTP methods and routes for API endpoints.

To get started, navigate to the Endpoints folder and create a new file named BookEndpoints.cs. Add the following code to the file:

// Endpoints/BookEndpoints.cs



namespace bookapi_minimal.Endpoints
{
     public static class BookEndPoint
    {
        public static IEndpointRouteBuilder MapBookEndPoint(this IEndpointRouteBuilder app)
        {


            return app;
        }
    }
}

The BookEndpoints class contains a MapBookEndPoint method that returns an IEndpointRouteBuilder object. The IEndpointRouteBuilder object is used to define the HTTP methods and routes for the API endpoints. In the next sections, we will define the API endpoints for creating, reading, updating, and deleting books.

How to Create the AddBookAsync Books Endpoint

In this section, we will create the AddBookAsync endpoint. This endpoint will accept a Book object as a JSON payload and add it to the database. We will use the MapPost method to define the HTTP method and route for this endpoint.

Add the following code to the BookEndpoints class:

// Endpoints/BookEndpoints.cs


//...
   // Endpoint to add a new book
      app.MapPost("/books", async (CreateBookRequest createBookRequest, IBookService bookService) =>
        {
        var result = await bookService.AddBookAsync(createBookRequest);
        return Results.Created($"/books/{result.Id}", result); 
        });


//...

• Route Definition: The MapPost method defines the route for the endpoint as /books.

• Request Model: The endpoint accepts an CreateBookRequest object as a JSON payload. The CreateBookRequest object contains the data required to create a new book.

• Response Model: The endpoint returns a Book object as a JSON payload. The Book object contains the data for the newly created book.

• Return Value: The endpoint returns a Created result. The Created result contains the location of the newly created book and the Book object.

How to Create the GetBookAsync Book Endpoint

In this section, we will create the GetBookAsync endpoint. This endpoint will accept a book ID as a query parameter and return the book with the specified ID. We will use the MapGet method to define the HTTP method and route for this endpoint.

Add the following code to the BookEndpoints class:

// Endpoints/BookEndpoints.cs

// ...
    // Endpoint to get all books
    app.MapGet("/books", async (IBookService bookService) =>
     {
    var result = await bookService.GetBooksAsync();
    return Results.Ok(result);
});


//...

• Route Definition: The MapGet method defines the route for the endpoint as /books.

• Request Model: The endpoint accepts a Book object as a JSON payload. The Book object contains the data required to create a new book.

• Response Model: The endpoint returns a Book object as a JSON payload. The Book object contains the data for the newly created book.

• Return Value: The endpoint returns an Ok result. The Ok result contains the Book object.

How to Create the GetBookByIdAsync Book Endpoint

In this section, we will create the GetBookByIdAsync endpoint. This endpoint will accept a book ID as a route parameter and return the book with the specified ID. We will use the MapGet method to define the HTTP method and route for this endpoint.

Add the following code to the BookEndpoints class:

// Endpoints/BookEndpoints.cs
//...
// Endpoint to get a book by ID

  app.MapGet("/books/{id:guid}", async (Guid id, IBookService bookService) =>
  {
    var result = await bookService.GetBookByIdAsync(id);
    return result != null ? Results.Ok(result) : Results.NotFound();
});

//...

• Route Definition: The MapGet method defines the route for the endpoint as /books/{id:guid}. The {id:guid} parameter specifies that the id parameter should be a GUID.

• Request Model: The endpoint accepts a Book object as a JSON payload. The Book object contains the data required to create a new book.

• Response Model: The endpoint returns a Book object as a JSON payload. The Book object contains the data for the newly created book.

• Return Value: The endpoint returns an Ok result if the book is found. The NotFound result is returned if the book is not found.

How to Create the UpdateBookAsync Book Endpoint

In this section, we will create the UpdateBookAsync endpoint. This endpoint will accept a book ID as a route parameter and an Book object as a JSON payload and update the book with the specified ID. We will use the MapPut method to define the HTTP method and route for this endpoint.

Add the following code to the BookEndpoints class:

// Endpoints/BookEndpoints.cs

//...
   // Endpoint to update a book by ID
    app.MapPut("/books/{id:guid}", async (Guid id, UpdateBookRequest updateBookRequest, IBookService bookService) =>
 {
var result = await bookService.UpdateBookAsync(id, updateBookRequest);
return result != null ? Results.Ok(result) : Results.NotFound();
});

//...

• Route Definition: The MapPut method defines the route for the endpoint as /books/{id:guid}. The {id:guid} parameter specifies that the id parameter should be a GUID.

• Request Model: The endpoint accepts a Book object as a JSON payload. The Book object contains the data required to create a new book.

• Response Model: The endpoint returns a Book object as a JSON payload. The Book object contains the data for the newly created book.

• Return Value: The endpoint returns an Ok result if the book is found. The NotFound result is returned if the book is not found.

How to Create the DeleteBookAsync Book Endpoint

In this section, we will create the DeleteBookAsync endpoint. This endpoint will accept a book ID as a route parameter and delete the book with the specified ID. We will use the MapDelete method to define the HTTP method and route for this endpoint.

Add the following code to the BookEndpoints class:

// Endpoints/BookEndpoints.cs

//...
   // Endpoint to delete a book by ID
 app.MapDelete("/books/{id:guid}", async (Guid id, IBookService bookService) =>
{
var result = await bookService.DeleteBookAsync(id);
   return result ? Results.NoContent() : Results.NotFound();
});


//...

• Route Definition: The MapDelete method defines the route for the endpoint as /books/{id:guid}. The {id:guid} parameter specifies that the id parameter should be a GUID.

• Request Model: The endpoint accepts a Book object as a JSON payload. The Book object contains the data required to create a new book.

• Response Model: The endpoint returns a Book object as a JSON payload. The Book object contains the data for the newly created book.

• Return Value: The endpoint returns a NoContent result if the book is deleted successfully. The NotFound result is returned if the book is not found.

Now we have defined all the methods for the book endpoints. So your endpoint class should look like this:

// Endpoints/BookEndpoints.cs
using bookapi_minimal.Contracts;
using bookapi_minimal.Interfaces;

namespace bookapi_minimal.Endpoints
{
     public static class BookEndPoint
    {
        public static IEndpointRouteBuilder MapBookEndPoint(this IEndpointRouteBuilder app)
        {
            // Define the endpoints

            // Endpoint to add a new book
            app.MapPost("/books", async (CreateBookRequest createBookRequest, IBookService bookService) =>
            {
                var result = await bookService.AddBookAsync(createBookRequest);
                return Results.Created($"/books/{result.Id}", result); 
            });


               // Endpoint to get all books
            app.MapGet("/books", async (IBookService bookService) =>
            {
                var result = await bookService.GetBooksAsync();
                return Results.Ok(result);
            });

            // Endpoint to get a book by ID
            app.MapGet("/books/{id:guid}", async (Guid id, IBookService bookService) =>
            {
                var result = await bookService.GetBookByIdAsync(id);
                return result != null ? Results.Ok(result) : Results.NotFound();
            });


            // Endpoint to update a book by ID
            app.MapPut("/books/{id:guid}", async (Guid id, UpdateBookRequest updateBookRequest, IBookService bookService) =>
            {
                var result = await bookService.UpdateBookAsync(id, updateBookRequest);
                return result != null ? Results.Ok(result) : Results.NotFound();
            });

            // Endpoint to delete a book by ID
            app.MapDelete("/books/{id:guid}", async (Guid id, IBookService bookService) =>
            {
                var result = await bookService.DeleteBookAsync(id);
                return result ? Results.NoContent() : Results.NotFound();
            });

            return app;
        }
    }
}

Congratulations! You have created all the endpoints for the book API. The endpoints handle the CRUD operations for books and return the appropriate responses based on the request and data.

How to Register the Endpoints

After defining the API endpoints for the book API, the next step is to register these endpoints in the Program.cs file. We will use the MapBookEndpoints method to register the book endpoints.

We should also clean up our Program.cs class to ensure it remains organized and maintainable.

// Program.cs

using System.Reflection;
using bookapi_minimal.Endpoints;
using bookapi_minimal.Services;
using Microsoft.OpenApi.Models;

var builder = WebApplication.CreateBuilder(args);


builder.AddApplicationServices();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen(c=>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "Mimal API", Version = "v1", Description = "Showing how you can build minimal " +
        "api with .net" });


    // Set the comments path for the Swagger JSON and UI.
    var xmlFile = $"{Assembly.GetExecutingAssembly().GetName().Name}.xml";
    var xmlPath = Path.Combine(AppContext.BaseDirectory, xmlFile);
    c.IncludeXmlComments(xmlPath);

});
var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseExceptionHandler();


app.MapGroup("/api/v1/")
   .WithTags(" Book endpoints")
   .MapBookEndPoint();

app.Run();

Let's break down the key components of the Program.cs file:

• AddApplicationServices: This method registers the necessary services for the API. It is an extension method we created earlier to add services to the dependency injection container.

• AddSwaggerGen: This method registers the Swagger generator, which is used to create the Swagger documentation for the API. We specify the title, version, and description of the API in the Swagger document.

• MapGroup: This method groups the endpoints. It takes a path as a parameter and returns an IEndpointRouteBuilder object. We use the WithTags method to add tags to the endpoints and the MapBookEndpoints method to register the book endpoints.

• Run: This method starts the application.

To enable Swagger documentation, you need to add the GenerateDocumentationFile property to your .csproj file. In this example, the file is named bookapi-minimal.csproj, but the name may vary based on your project.

Add the following line to your .csproj file:

<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>

By the end, bookapi-minimal.csproj should look like this:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
     <GenerateDocumentationFile>true</GenerateDocumentationFile>
    <RootNamespace>bookapi_minimal</RootNamespace>
  </PropertyGroup>

  <ItemGroup>
   <PackageReference Include="FluentValidation.DependencyInjectionExtensions" Version="11.9.2" />
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="8.0.6" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.8" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="8.0.8">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="8.0.8" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="8.0.8">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
  </ItemGroup>

</Project>

Now that we have registered the book endpoints in the Program.cs file, we can run the application and test the API endpoints using Swagger.

When you run the application, you should see the Swagger documentation at the following URL: https://localhost:5001/swagger/index.html. The Swagger documentation provides information about the API endpoints, request and response models, and allows you to test the endpoints directly from the browser. You should see something like this:

Congratulations! You have implemented the business logic for the book service, created custom exceptions, defined API endpoints, and registered the endpoints in the Program.cs file. You have also enabled Swagger documentation to test the API endpoints.

How to Add Seed Data to the Database

One more important step is to seed the database with initial data when the application starts. This seed data will populate the database, allowing you to test your API endpoints without manually adding data.

Let's add some seed data before performing migrations and testing our API endpoints.

To achieve this, we will create a new class in our Configuration folder called BookTypeConfigurations and add the following code:

using bookapi_minimal.Models;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

namespace bookapi_minimal.Configurations
{
    public class BookTypeConfigurations : IEntityTypeConfiguration<BookModel>
    {
        public void Configure(EntityTypeBuilder<BookModel> builder)
        {
            // Configure the table name
            builder.ToTable("Books");

            // Configure the primary key
            builder.HasKey(x => x.Id);

            // Configure properties
            builder.Property(x => x.Id).ValueGeneratedOnAdd();
            builder.Property(x => x.Title).IsRequired().HasMaxLength(100);
            builder.Property(x => x.Author).IsRequired().HasMaxLength(100);
            builder.Property(x => x.Description).IsRequired().HasMaxLength(500);
            builder.Property(x => x.Category).IsRequired().HasMaxLength(100);
            builder.Property(x => x.Language).IsRequired().HasMaxLength(50);
            builder.Property(x => x.TotalPages).IsRequired();

            // Seed data
            builder.HasData(
                new BookModel
                {
                    Id = Guid.NewGuid(),
                    Title = "The Alchemist",
                    Author = "Paulo Coelho",
                    Description = "The Alchemist follows the journey of an Andalusian shepherd",
                    Category = "Fiction",
                    Language = "English",
                    TotalPages = 208
                },
                new BookModel
                {
                    Id = Guid.NewGuid(),
                    Title = "To Kill a Mockingbird",
                    Author = "Harper Lee",
                    Description = "A novel about the serious issues of rape and racial inequality.",
                    Category = "Fiction",
                    Language = "English",
                    TotalPages = 281
                },
                new BookModel
                {
                    Id = Guid.NewGuid(),
                    Title = "1984",
                    Author = "George Orwell",
                    Description = "A dystopian social science fiction novel and cautionary tale about the dangers of totalitarianism. ",
                  Category = "Fiction",
                  Language = "English",
                  TotalPages = 328
                } 
            );
        }
    }
}

Let's break down the code above:

In Entity Framework Core, you can use the IEntityTypeConfiguration interface to configure the entity type and seed data for the database. The BookTypeConfigurations class implements the IEntityTypeConfiguration<BookModel> interface and provides the configuration for the BookModel entity.

• Configure Method: This method is used to configure the BookModel entity type. It defines the table name, primary key, and properties for the BookModel entity.

  • Table Name: The ToTable method specifies the name of the table to be created in the database. In this case, the table name is set to "Books".

  • Primary Key: The HasKey method specifies the primary key for the BookModel entity. The primary key is set to the Id property.

  • Properties: The Property method configures the properties of the BookModel entity. It specifies the data type, length, and constraints for each property.

• Seed Data: The HasData method seeds the database with initial data. It creates three BookModel objects with sample data for testing the API endpoints.

Now that we have created the BookTypeConfigurations class, we need to register this configuration in the ApplicationContext class. This ensures that the configuration is applied when the database is created or migrated.

We’re finally almost ready to test our API. But before we do that, we need to perform migrations to create the database and apply the seed data.

Remember that we added our database connection string in the appsettings.json file? Now let's perform a migration and later update our database for the migration to take effect.

How to Perform a Migration

Migrations allow you to update the database schema based on changes made to your model classes. In Entity Framework Core, you can use the dotnet ef migrations add command to create a new migration reflecting these changes.

To perform a migration, run the following command in the terminal:

dotnet ef migrations add InitialCreate

If the command is successful, you should see an output similar to this:

Build started...
Build succeeded.
Done. To undo this action, use 'ef migrations remove'

You will now see a new folder called Migrations in your project. This folder contains the migration files that were created based on the changes made to your model classes. These migration files include the SQL commands required to update the database schema.

How to Update the Database

After creating the migration, you need to apply the migration to update the database schema. You can use the dotnet ef database update command to apply the migration and update the database. Make sure the SQL Server is running.

Run the following command in the terminal:

dotnet ef database update

This will update the database schema based on the changes made to your model classes. Make sure there are no errors on your database connection string.

How to Test the API Endpoints

Now we can test our endpoints using Swagger. To do this, run the application by executing the following command in the terminal:

dotnet run

This will run our application. You can open your browser and navigate to https://localhost:5001/swagger/index.html to access the Swagger documentation. You should see a list of API endpoints, request and response models, and the ability to test the endpoints directly from the browser.

If your port number is different from 5001, don't worry – it will still work. The port might change depending on the type of machine you're using, but it will still achieve the same result.

How to Test the Get All Books Endpoint

To test the Get All Books endpoint, follow these steps:

1. In the Swagger documentation, click on the GET /api/v1/books endpoint.

2. Click the Try it out button.

3. Click the Execute button.

This will send a request to the API to retrieve all the books in the database.

You should see the response from the API, which will include the list of books that were seeded in the database.

The image below shows the response from the API:

How to Test the Get Book by ID Endpoint

To test the Get Book by ID endpoint, follow these steps:

1. In the Swagger documentation, click on the GET /api/v1/books/{id} endpoint.

2. Enter the ID of a book in the id field. You can use one of the book IDs that was seeded in the database.

3. Click the Try it out button.

This will send a request to the API to retrieve the book with the specified ID. You should see the response from the API, which will include the book with the specified ID.

The image below shows the response from the API:

How to Test the Add Book Endpoint

To test the Add Book endpoint, follow these steps:

1. In the Swagger documentation, click on the POST /api/v1/books endpoint.

2. Click the Try it out button.

3. Enter the book details in the request body.

4. Click the Execute button.

This will send a request to the API to add a new book to the database.

You should see the response from the API, which will include the newly created book.

The image below shows the response from the API:

How to Test the Update Book Endpoint

To test the Update Book endpoint, follow these steps:

1. In the Swagger documentation, click on the PUT /api/v1/books/{id} endpoint.

2. Enter the ID of a book in the id field. You can use the id of one of the books that we just added.

3. Click the Try it out button.

This will send a request to the API to update the book with the specified ID.

You should see the response from the API, which will include the updated book.

The image below shows the response from the API:

How to Test the Delete Book Endpoint

To test the Delete Book endpoint, follow these steps:

1. In the Swagger documentation, click on the DELETE /api/v1/books/{id} endpoint.

2. Enter the ID of a book in the id field. You can use any of the ids from the books that we just added or the seeded data.

3. Click the Try it out button.

This will send a request to the API to delete the book with the specified ID.

The image below shows the response from the API:

Congratulations! You have implemented all the CRUD operations for books and tested the API endpoints using Swagger, verifying that they work as expected. You can now build on this foundation to add more features and functionality to your API.

Conclusion

This handbook explored how to create a minimal API in ASP.NET Core with .NET 8. We built a comprehensive book API that supports CRUD operations, implemented custom exceptions, defined and registered API endpoints, and enabled Swagger documentation for easy testing.

Following this tutorial, you have gained a solid foundation for building minimal APIs with ASP.NET Core. You can now apply this knowledge and create robust APIs for various domains and industries.

I hope you found this tutorial both helpful and informative. Thank you for reading!

Feel free to connect with me on social media:

• Twitter

• LinkedIn

• GitHub