kawser2133/clean-structured-api-project

This is a .NET-based REST API application designed to manage customers, orders, and products. It implements a layered architecture with a public API layer, a core domain layer for business logic and data models, and an infrastructure layer handling Entity Framework Core database operations. The system exposes standard CRUD endpoints for these entities, supported by automated unit tests and performance benchmarking capabilities.

New API controllers have been introduced for Customers, Orders, and Products, each exposing endpoints for listing (including paginated views), retrieving, creating, updating, and deleting resources. The ProductController also includes a PriceCheck endpoint. These controllers implement standard CRUD operations with error handling and logging, enabling external clients to manage these core business entities via the REST API.

Project.API/Controllers · high confidence

The core project now includes new entity models (Customer, Order, OrderDetails, Product) and their corresponding ViewModels, along with a generic PaginatedDataViewModel for list operations. To support these entities, the update introduces a generic base repository interface (IBaseRepository) and specific repository interfaces (ICustomerRepository, IOrderRepository, etc.), as well as service interfaces (ICustomerService, IOrderService, IProductService) and their implementations. This establishes the foundational data access and business logic layers for managing customers, orders, and products.

Project.Core · high confidence

Users can now evaluate the performance of order-related endpoints through new benchmark tests in the API extension layer. Additionally, the application's dependency injection container is configured to register services and repositories for customers, products, and orders, along with corresponding AutoMapper mappings for their view models.

Project.API/Extensions · high confidence

The API now includes a custom middleware that logs incoming HTTP requests and outgoing responses, including headers and status codes, to the application logger. Additionally, a new endpoint at /runbenchmarks has been added to trigger performance benchmarks using BenchmarkDotNet, and the application builder has been updated to register the logging services and map controllers.

Project.API · high confidence

The application now includes a new Entity Framework Core database context (ApplicationDbContext) and an initial migration that creates tables for Users, Roles, Customers, Products, Orders, and OrderDetails. The data layer is populated with 100 fake customers, 100 fake products, and 1,000 fake orders via the configuration class. A generic BaseRepository and specific repositories (Customer, Product, Order, OrderDetails) have been added to provide data access, including a specialized query for retrieving an order with its associated customer and line items.

Project.Infrastructure · high confidence

The repository was initialized with a standard .NET solution structure (Clean.API.Project.sln) containing four main projects: Project.Core, Project.Infrastructure, Project.API, and Project.UnitTest. A .gitignore file was added to exclude common build artifacts and IDE-specific files. The project is licensed under the MIT License, and the README.md was updated to provide comprehensive documentation on the project's architecture, features, and usage instructions.

(repo-wide) · high confidence

Added unit tests for the Product domain, including tests for the ProductController, ProductService, and ProductRepository to verify the behavior of the product management features.

Project.UnitTest · high confidence

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

• CAI 38 → 38 (-0.0)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 73 → 72 (-1.1)
• Architecture 84 → 84 (+0.0)
• Maturity 56 → 56 (+0.0)
• Readiness 32 → 32 (+0.0)
• Security 25 → 25 (+0.1)
• Performance 79 → 79 (+0.0)

• Inconsistent naming for creation and retrieval operations: some services use 'Create' while others might use 'Add' or 'Insert'; similarly, retrieval uses 'Get', 'GetOrders', 'GetProducts', 'GetCustomer' inconsistently.
• Inconsistent naming for order details: some use 'OrderDetails' as a collection or object, while others use 'OrderDetail' or 'OrderDetailsViewModel'.
• Inconsistent naming for product attributes: some are in 'Business' namespace as ViewModels, while others are in 'General' namespace as Entities.
• Inconsistent naming for the same or similar business logic: some services use 'IsExists' while others use 'IsExistsForUpdate' for checking existence, and some implementations use 'IsExists' while others use 'IsExistsForUpdate'.
• Inconsistent naming for update operations: some services use 'Update' while the base repository also uses 'Update', but the parameter types and signatures vary significantly, suggesting different underlying behaviors.
• Medium CVE: Azure.Identity 1.6.0
• Medium CVE: Azure.Identity 1.6.0
• No exposed public API
• Secret: generic-api-key (Project.API/appsettings.json)
• early-stage repository — too little history to judge knowledge freshness
• single-maintainer — knowledge-concentration (bus factor) risk

• CommentedOutCode (Project.Infrastructure/Repositories/OrderRepository.cs)
• Documentation: no installation or build instructions (README.md)
• Duplicated block (5 lines × 2) (Project.Core/Entities/Business/CustomerViewModel.cs)
• End-of-life runtime: .NET net7.0
• High secret: WD-SECRET-0002 (Project.API/appsettings.json)
• Inconsistent naming for existence checks: some methods are named IsExists while others are named IsExistsForUpdate. These appear to serve similar validation purposes (checking if a record exists) but have different names, causing confusion about whether the 'ForUpdate' suffix implies a specific locking strategy or just a different validation context.
• Inconsistent naming for retrieval methods: GetOrders vs GetPaginatedOrders. While GetPaginatedOrders is descriptive, the existence of GetOrders without pagination parameters suggests a lack of standardization on how to handle large datasets. It is unclear if GetOrders returns all records (potentially inefficient) or if it's an alias for a default pagination.
• Inconsistent naming for the customer reference in Order entities: CustomerName in the ViewModel vs Customer in the General entity. CustomerName implies a string property, while Customer implies an object reference. This creates ambiguity about whether the ViewModel property is a string or an object, and breaks the parallel structure with OrderDetails (which is an object reference in both Order and OrderDetailsViewModel contexts, though OrderDetails is plural in one and singular in the other's relationship).
• WriteOnlyPrivateField (Project.Core/Services/OrderService.cs)

• Unchanged — 1 containers · 0 contexts · 0 edges

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

kawser2133/clean-structured-api-project 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.