Forem: Jervie Gono

Part 3 of My First .NET Core Web API Project: Documenting the Rookie Mistakes and Wins on the Way to a Job.

Jervie Gono — Sun, 23 Nov 2025 01:32:22 +0000

Creating Identity Entities

We will now Proceed on Creating Authentication and Authorization
Which where we will be using Asp.netcore Identity

We need 2 Entities:

ApplicationUser
ApplicationRole

The Application User will be used for User Account and doesn't have any connection to our other entities such categories or products. This where Account will handle Authentication

The application Role is basically the Role would be assigned from user. In our case we will assigning role base on their emails.
We will also creating 3 Roles
-Admin
-Seller
-Costumer

Configuration and Fluent Api

Using IEntityTypeConfiguration<>
-We will be using this for extensively configuring database models and relationships.

ApplicationUserConfiguration: This were the ApplicationUser configured it's properties:

it's properties and relationships
-CategoryConfiguration: This were the Category configured it's properties :

public void Configure(EntityTypeBuilder<Category> builder)
{
    builder.ToTable("Categories");

    builder.HasKey(c => c.CategoryId);

    builder.Property(c => c.Name)
        .IsRequired()
        .HasMaxLength(100);

    builder.Property(c => c.Description)
        .HasMaxLength(500);

    //relationships to seller and parent category
    builder.HasOne(c => c.Seller)
        .WithMany(x => x.Categories)
        .HasForeignKey(c => c.SellerId)
        .OnDelete(DeleteBehavior.SetNull);

    //relationship for parent category
    builder.HasOne(c => c.ParentCategory)
        .WithMany(c => c.SubCategories)
        .HasForeignKey(c => c.ParentCategoryId)
        .OnDelete(DeleteBehavior.Restrict);
}

And the other configuration follow the same pattern.
Also doing configuration requires understanding about your own Validation. Whether it was fluent validation or Data annotation.

Database Migration and Update Database

We are adding the IdentityDbContext here and we will also apply configuration that we did using ApplyConfigurationsFromAssembly.

 public class ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : IdentityDbContext<ApplicationUser, ApplicationRole, Guid>(options)
 {
     public virtual DbSet<ApplicationUser> ApplicationUsersDb { get; set; } = null!;
     public virtual DbSet<Category> CategoriesDb { get; set; } = null!;
     public virtual DbSet<Product> ApplicationRolesDb { get; set; } = null!;
     public virtual DbSet<Order> OrderDb { get; set; } = null!;
     public virtual DbSet<OrderItem> OrderItemDb { get; set; } = null!;
     public virtual DbSet<Review> ReviewDb { get; set; } = null!;

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

         builder.ApplyConfigurationsFromAssembly(typeof(ApplicationDbContext).Assembly);

         builder.ApplyConfigurationsFromAssembly(typeof(CategoryConfiguration).Assembly);
         builder.ApplyConfigurationsFromAssembly(typeof(ProductConfiguration).Assembly);
         builder.ApplyConfigurationsFromAssembly(typeof(OrderItemConfiguration).Assembly);
         builder.ApplyConfigurationsFromAssembly(typeof(OrderConfiguration).Assembly);
         builder.ApplyConfigurationsFromAssembly(typeof(ReviewConfiguration).Assembly);
     }
 }

Before we can do Migration
We need to add DbContextFactory:
ApplicationDbContextFactory : IDesignTimeDbContextFactory

Why? In a clean architecture, DbContext lives in the Infrastructure project,
But the EF Core migration tools (dotnet ef migrations add ...) run outside your application—
meaning:

They cannot access your Program.cs
They cannot read your DI container
They do NOT know how to create your DbContext
They do NOT run the host builder
They do NOT use your app’s configuration pipeline

After that we will just need to go in User-Secret and add our "ConnectionStrings"

Then Do command: Add-migration and Update-Database

Now The Migration will be added:

After these steps We can now move to Creating Repositories.

What's Next?
In Part 4, I will Implement Authentication and Authorization by doing the Following:

Creating IAuthService in our Core Application and implement that inside services in our infrastructure
We will also implement Refresh tokens and Jwt tokens in general -We will assign the role for user base on their email

Part 2 of My First .NET Core Web API Project: Documenting the Rookie Mistakes and Wins on the Way to a Job.

Jervie Gono — Thu, 20 Nov 2025 23:50:38 +0000

Creating our Core Domain Entities

It can be challenging to choose our models.
You should consider the long-term effects before committing and making a decision. Initially, I made the decision to include numerous other options, like payment, shopping cart, product variant, product image, and so forth. However, I am aware that the project will take more than six months to complete, and as I am a lone developer, I may not be able to finish it.

Core/Entities and their relationship

> - Category
- > Contains products
- > Navigation: Products collection
- > Used by seller/admin to organize items
- > Self-referencing for subcategories

> - Product
- > Belongs to Category
- > Navigation: OrderItems, Reviews
- > Shown in shop menu to customers
- > Can be added/updated by seller

> - Order
- > Created when a customer buys items
- > Contains multiple OrderItems
- > Status tracks the overall order (Pending, Confirmed, Shipped, Delivered, Cancelled)
- > TotalAmount = sum of OrderItem.UnitPrice * Quantity
- > Managed mostly by backend (seller/admin)

> - OrderItem
- > Snapshot of a product at the time of order
- > Contains UnitPrice, Quantity
- > Navigation to Order and Product

> - Review
- > Written by customer
- > Only creation is needed (no update)
- > Linked to Product and User`

Now that our model and entities are completed
We go on to our Dto. Data Transfer Object (DTO)
Planning is necessary in various ways.

//our Dtos category for httpPost
 public record CategoryRequestDto
 {
     public string Name { get; init; } = string.Empty;
     public string? Description { get; init; }
 }

Why are records being used here?
Because we are striving for immutability, which classes do not have

PS: We also need to put Enums in Shared, Why? same reason for Dtos: Dependency Management.

Also, Enums often represent fundamental, non-changing data points that are used across multiple layers.

Validation

We're setting a standard here: Fluent Validation is our primary validation tool. While the built-in Data Annotations are fine for quick setups, we're phasing them out for consistency and enterprise readiness.

In the world of real-deal, production-level applications—especially larger ones—Fluent Validation is the industry favorite. Getting comfortable with its clear, code-based approach now is a huge win for future projects.

Sample code:

internal class CategoryRequestValidation : AbstractValidator<CategoryRequestDto>
{
    protected CategoryRequestValidation()
    {
        RuleFor(x => x.Name)
            .NotEmpty().WithMessage("Category name is required.")
            .MaximumLength(100).WithMessage("Category name must not exceed 100 characters.");

        RuleFor(x => x.Description)
            .MaximumLength(500).WithMessage("Category description must not exceed 500 characters.");
    }

}

Lastly we just register it in our Dependency Injection

/// <summary>
/// Creates extension methods for registering services in the Infrastructure layer.
/// </summary>
public static class DependencyInjection
{
    public static IServiceCollection AddInfrastructure(this IServiceCollection services)
    {
        #region
        //Category Validation
        services.AddValidatorsFromAssemblyContaining<CategoryRequestValidation>();
        services.AddValidatorsFromAssemblyContaining<CategoryUpdateValidation>();
//The rest of Codes

What's Next?

In Part 3, I'll dive into implementing the base architecture with:

Creating DbContext
Configuring Secret User
Registering services in Program.cs
Prepare for Identity

My First .NET Core Web API Project: Documenting the Rookie Mistakes and Wins on the Way to a Job.

Jervie Gono — Wed, 19 Nov 2025 03:32:27 +0000

The Blueprint - Planning My E-Commerce API Architecture

My First .NET Core Web API Project: Part 1 - Architecture & Planning

Why an E-Commerce API?

When I decided to build my portfolio project, I knew I needed something that would demonstrate real-world skills. An e-commerce API was perfect because it touches on:

User management (authentication, profiles)
Product catalog (CRUD, search, pagination)
Business logic (inventory, orders, payments)
Security (data isolation, input validation)

The architecture decision: Clean Architecture

I almost started with a traditional layered architecture, but then I discovered Clean Architecture. Here's why I chose it:

Ecommerce/
├── API/ # ASP.NET Core Web API
├── Core/ # Domain models, business logic
├── Infrastructure/# Data access, external services
└── Shared/ # DTOs, common utilities

Technology Stack Choices

Backend Framework: ASP.NET Core 8

Why I Chose It: Latest features, performance improvements, long-term support
Learning Experience: Initially considered .NET 6 for stability, but embracing the latest version demonstrates adaptability

Database: SQLSERVER

Why I Chose It: Because it was often most used in .net core projects
Consideration: Using Postgresql is a good choice too, but for this project we choose not to use it.

ORM: Entity Framework Core

Why I Chose It: Productivity with LINQ + raw SQL control when needed
Key Learning: Understanding when to use LINQ vs direct SQL for performance

Key Design Patterns

1. CQRS with MediatR

// Commands for write operations
public record CreateProductCommand(CreateProductDto Product) 
    : IRequest<ResponseType<ProductDto>>;

// Queries for read operations  
public record GetProductByIdQuery(Guid Id) 
    : IRequest<ResponseType<ProductDto>>;

We will also adding Repository so our project don't have to be strictly tied in any SQL

public interface IProductRepository
{
    Task<Product> GetByIdAsync(Guid id);
    Task<PaginatedResult<Product>> GetPaginatedAsync(PaginationRequest request);
}

What's Next?

In Part 2, I'll dive into implementing the base architecture with:

Dependency injection configuration
Models
DTOs
Enums -Validation