SaraRasoulian/DotNet-WebAPI-Blazor-Sample

This is a student management system built on a .NET 8 architecture, featuring a Blazor client and a WebAPI server. The server implements a clean architecture with distinct layers for domain logic, application services, and data persistence, exposing RESTful endpoints for full student CRUD operations. The system includes comprehensive automated testing and is fully containerized for deployment.

The client application now includes a Dockerfile that builds the .NET 8.0 application and serves the static output via Nginx on port 8080. A corresponding nginx.conf configures the server to serve the built web files, and a .dockerignore file excludes build artifacts and user-specific files from the Docker context. These changes enable containerized deployment of the client.

client · medium confidence

The server's infrastructure layer now includes the complete data access setup for the Student entity. This adds the Student entity's EF Core configuration, a StudentManagementDBContext, a StudentRepository implementing IStudentRepository, and the initial database migration (v1) that creates the Students table with unique constraints on email and GitHub username. The dependency injection registration for the DbContext and repository is also included.

server/src/Infrastructure · high confidence

The client application now includes a complete set of Razor pages for managing students, including a home page, a student list, and individual pages for viewing, adding, editing, and deleting students. The implementation features client-side validation using DataAnnotations on the StudentDto, a dedicated StudentService for HTTP requests, and a MainLayout component that provides a responsive sidebar navigation and header. The layout includes a toggleable sidebar for desktop and a mobile-friendly navbar, styled with Bootstrap 5.1.0.

client/src · high confidence

Users can now create, read, update, and delete student records through new command and query handlers in the Application layer. This includes CreateStudentHandler, DeleteStudentHandler, UpdateStudentHandler, GetAllStudentsHandler, and GetStudentByIdHandler. The domain layer introduces the Student entity with properties for first name, last name, email, birth date, and GitHub username, along with base entity classes for auditing and identity. The IStudentRepository interface defines the data access contract, and the Email value object enforces validation rules for email addresses.

server/src/Application/Students/Handlers/CommandHandlers, server/src/Application/Students/Handlers/QueryHandlers, server/src/Domain · high confidence

The WebAPI project is introduced with a new directory structure, including the main entry point (Program.cs) which configures dependency injection, Swagger, and CORS policies for both local and Docker-based client applications. A new StudentsController is added to expose REST endpoints for student management, and a GlobalExceptionHandler middleware is implemented to standardize error responses. Configuration files (appsettings) and launch settings are also added to support development and Docker environments.

server/src/WebAPI · high confidence

The Application layer now supports full student lifecycle operations, including creating, updating, and deleting students, as well as retrieving them by ID or listing all. This is enabled by new MediatR commands and queries, corresponding validators that enforce business rules (such as unique email and GitHub username constraints), and request/response models. A global validation pipeline behavior is registered to automatically validate incoming commands.

server/src/Application · high confidence

The server codebase has been reorganized into a dedicated 'server' directory, accompanied by the addition of a Dockerfile and a .dockerignore file to support containerized builds. The solution file (StudentManagement.Server.sln) has been updated to reflect the new folder structure, grouping the WebAPI, Domain, Application, and Infrastructure projects under a 'src' folder, while test projects are organized under 'tests'.

server · medium confidence

Added unit, integration, and acceptance tests for the Student Management feature. The changes include unit tests for all student handlers (Create, Read, Update, Delete, and GetAll) using mocked repositories, integration tests for the StudentsController endpoints, and acceptance tests using SpecFlow to verify the full API lifecycle (CRUD operations) against a test database.

server/tests · high confidence

The server-side .NET projects have been upgraded to .NET 8, including the WebAPI, Application, Domain, and Infrastructure projects. This update introduces several new or updated dependencies: Blazor.Bootstrap 2.2.0 and ASP.NET Core WebAssembly 8.0.2 on the client side; FluentValidation 11.9.1, Mapster 7.4.0, and MediatR 12.2.0 in the application layer; and EF Core 8.0.4 with Npgsql 8.0.2 for database interactions. The WebAPI project now includes Swashbuckle for OpenAPI documentation. Additionally, the test suite has been updated with xUnit 2.4.2, NSubstitute 5.1.0, Bogus 35.5.1, and SpecFlow 3.9.74 to support the new framework version.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 61 → 60 (-1.4)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 74 → 64 (-9.4)
• Architecture 92 → 91 (-0.5)
• Maturity 82 → 82 (+0.0)
• Readiness 57 → 57 (+0.0)
• Security 87 → 87 (-0.7)
• Accessibility 53 → 53 (+0.0)

• Bounded contexts not declared
• Build status unknown
• Coverage not measured — analyzer environment
• Duplicated block (23 lines × 2) (server/src/Application/Students/Commands/CreateStudentCommandValidator.cs)
• Monorepo: only 1 of 2 solutions was scored
• No exposed public API
• The Docker run instructions mention starting with docker-compose but do not state how to build or publish the application. (README.md)
• no production source files with tracked history to analyse
• single-maintainer — knowledge-concentration (bus factor) risk

• Documentation: no contributor guidance (README.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (32 lines × 2) (server/src/Application/Students/Commands/CreateStudentCommandValidator.cs)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• Inconsistent naming for the same test scenario across unit and integration tests. The unit test method is named CreateStudentHandler_Returns_StudentResponse, implying it tests the Handler. The integration test method is named CreateStudentCommand_Returns_StudentResponse, implying it tests the Command. Since both are in StudentHandlersTests (or related handler test classes) and test the same end-to-end flow of creating a student, the naming should be consistent. The integration test class is StudentHandlersTests, so the method should likely follow the handler naming convention.
• Inconsistent return value description in test names. The unit test GetAllStudentsHandler_Returns_Students correctly indicates a collection of students. The integration test GetAllStudentsHandler_Returns_StudentResponse uses the DTO type name instead of the count/quantity description, which is inconsistent with the unit test and less descriptive of the behavior (returning multiple items).
• Medium IaC: WD-DOCKER-0003 (client/Dockerfile)
• Medium IaC: WD-DOCKER-0003 (server/Dockerfile)
• Medium IaC: WD-DOCKER-0003 (server/Dockerfile)
• Property name inconsistency for the same domain concept. The entity uses PascalCase 'FirstName', while the DTO uses 'FirstName'. While this is technically consistent casing, the broader context shows 'Id' vs 'Id' and 'Email' vs 'Email'. However, looking at 'GitHubUsername' in Entity vs 'GitHubUsername' in DTO, they are consistent. Wait, looking closer at the list: Domain.Entities.Student.FirstName vs WebAPI.Tests.Acceptance.Dtos.StudentDto.FirstName. These are identical. Let's look for actual differences. Domain.Entities.Student.GitHubUsername vs WebAPI.Tests.Acceptance.Dtos.StudentDto.GitHubUsername. Identical. Domain.Entities.Student.Email vs WebAPI.Tests.Acceptance.Dtos.StudentDto.Email. Identical. Domain.Entities.Student.Id (inherited from EntityBase) vs WebAPI.Tests.Acceptance.Dtos.StudentDto.Id. Identical. Domain.Entities.Student.BirthDate vs WebAPI.Tests.Acceptance.Dtos.StudentDto.BirthDate. Identical.

Let's look at methods. IsEmailUnique is used in StudentRepository (Interface and Impl) and CreateStudentCommandValidator and UpdateStudentCommandValidator. The names are consistent. IsGitHubUsernameUnique is used in StudentRepository and CreateStudentCommandValidator and UpdateStudentCommandValidator. Consistent.

Let's look at test names. GetStudentByIdHandler_With_ValidId_Returns_StudentResponse vs GetStudentByIdHandler_With_InvalidId_Returns_Null. Consistent pattern. CreateStudentCommand_Returns_StudentResponse vs CreateStudentHandler_Returns_StudentResponse. The handler test uses CreateStudentHandlerTests class and method CreateStudentHandler_Returns_StudentResponse. The integration test class StudentHandlersTests has method CreateStudentCommand_Returns_StudentResponse. This is a naming inconsistency between the unit test method name and the integration test method name for the same logical action (creating a student). One refers to the 'Handler', the other to the 'Command'.

• redundant comment (server/src/Infrastructure/DependencyInjection.cs)

• Unchanged — 5 HTTP endpoints

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

SaraRasoulian/DotNet-WebAPI-Blazor-Sample was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.